analysis of an information system: namus

Running Head: ANALYSIS OF AN INFORMATION SYSTEM: NAMUS 1

Analysis of an Information System: NamUs

Teresa J. Rothaar

IST.8100: Integrating the Enterprise, IS Function/Technology

Wilmington University – Spring II 2015

ANALYSIS OF AN INFORMATION SYSTEM: NAMUS 2

Table of Contents

List of Figures & Tables ............................................................................................................... 3

Analysis of an Information System: NamUs .............................................................................. 4

Benefits and Disadvantages.......................................................................................................... 7

Holism vs. Reductionism .............................................................................................................. 7

Systems Development Life Cycle ................................................................................................. 8

Implementation Method Employed by Organization.............................................................. 11

Planning ....................................................................................................................................... 11

Planning Regarding Your System ............................................................................................. 12

Analysis ........................................................................................................................................ 13

Analysis Regarding Your System .............................................................................................. 13

Design ........................................................................................................................................... 14

Design Regarding Your System ................................................................................................. 14

Development ................................................................................................................................ 19

Development Regarding Your System ...................................................................................... 19

Testing .......................................................................................................................................... 21

Testing Regarding Your System ................................................................................................ 21

Implementation ........................................................................................................................... 22

Implementation Regarding Your System ................................................................................. 22

Maintenance ................................................................................................................................ 24

Maintenance Regarding Your System ...................................................................................... 24

Data Management – Data Backup/Disaster Recovery ............................................................ 25

Data Management – Data Backup/Disaster Recovery Regarding Your System .................. 26

Impact of Implementation.......................................................................................................... 26

References .................................................................................................................................... 31


List of Figures & Tables

Figure 1. Screenshot of a possible match between a missing person and an unidentified decedent.................................................................................................................................................. 6

Figure 2. NamUs UP data model.................................................................................................. 15 Figure 3. NamUs MP data model. ................................................................................................ 16 Figure 4. NamUs user types. ........................................................................................................ 17

Figure 5. Case submission and validation for MP cases entered by the general public. .............. 18 Figure 6. Registration and verification process for non-public users, such as law enforcement

personnel, case managers, and medical examiners. .............................................................. 19 Figure 7. NamUs network diagram. ............................................................................................. 20 Figure 8. NamUs organizational chart. ......................................................................................... 23


Analysis of an Information System: NamUs

NamUs, the National Missing and Unidentified Persons System, is an information system

consisting of two databases containing information on missing persons and unidentified

decedents in the United States and a web-based interface by which the databases can be accessed

by law enforcement professionals, coroners and medical examiners, and members of the general

public. NamUs is not just a software package; it is a true information system as defined by

Cohen, Dori, and de Haan: “a number of software products or modules put together” (2010, p.

21).

NamUs can be accessed for free online at www.namus.gov. NamUs was developed in

response to the “silent mass disaster” of missing persons and unidentified decedents in the U.S.

As a government system, NamUs is funded by a cooperative agreement with the National

Institute of Justice and operated by the National Forensic Science Technology Center. It does not

serve one organization in particular; it is used by law enforcement agencies, medical examiners,

and civilians around the country. At any given time, there are over 40,000 unidentified decedents

and 90,000 active missing person cases in the United States (National Institute of Justice, 2014).

However, until NamUs was developed, there was no single, nationwide repository to tie together

the records of missing people and unidentified decedents nationwide; every law enforcement

entity and medical examiner’s office was an island upon itself, and information was commonly

not shared across entities. Meanwhile, it is not uncommon for an individual to disappear in one

area of the country, yet die in another, possibly in an area where the missing person’s loved ones

had no idea they’d ever traveled, and thus where local law enforcement personnel are not looking

for them (M. Gregory, personal communication, April 21, 2015).

The NamUs system has two primary sections:

http://www.namus.gov/


The Unidentified Persons (UP) Database. This section of the system contains

information on unidentified decedents. Anyone can search the UP database on namus.gov,

filtering results by characteristics such as gender, age, race, location where the remains were

found, and even dental information. However, only medical examiners, coroners, and law

enforcement personnel can enter new cases into UP, and certain sensitive case information (such

as particularly graphic post-mortem photos or crime scene evidence that law enforcement wishes

to hold back) is hidden from public view.

The Missing Persons (MP) Database. This section contains information on missing

persons cases. While anyone can enter a new case into the MP database on namus.gov, before a

case entered by a member of the public goes live, it must be reviewed and approved by a NamUs

Regional System Specialist (RSS). Additionally, NamUs MP can be used to generate missing

persons posters and includes links to helpful resources for families and loved ones of missing

persons, such as state clearinghouses, law enforcement agencies, and victim assistance groups.

In 2012, NamUs was expanded to include a third section for unclaimed remains (UCP).

The decedents listed in NamUs UCP have been identified, but no one has come forward to claim

their remains. Only medical examiners and coroners can enter new cases into NamUs UCP, but

the database is publicly searchable using the decedent’s name and date of birth.

When a medical examiner, case manager, or law enforcement personnel enters a new

case into NamUs UP or NamUs MP, the system automatically attempts to cross-match the new

entry against the other database for possible matches (missing person to unidentified decedent or

vice versa) using similarities such as age, gender, and physical characteristics. Figure 1 (US

DOJ, 2010, p. 78) is a sample screenshot illustrating a possible match between a missing person

and an unidentified decedent.


Figure 1. Screenshot of a possible match between a missing person and an unidentified

decedent.

Along with being a technological investigative tool for law enforcement personnel,

NamUs is “is the first government-sponsored website of its kind to allow the general public to

view the profiles of missing persons and the unidentified dead” (US DOJ, 2011, p. 14). Civilian

users also have access to features such as requesting a free DNA sample kit that can be sent to

the University of North Texas, which handles both NamUs system maintenance and operates a


forensic laboratory where submitted DNA samples can be compared with an unidentified

decedent in NamUs UP (M. Gregory, personal communication, April 21, 2015).

Benefits and Disadvantages

According to M. Gregory, the biggest advantage to NamUs is the “crowdsourcing” aspect

of the database; by allowing the public to view missing persons and unidentified dead cold cases

from around the country, law enforcement officials have received tips that resulted in them

solving cases that had languished for years, sometimes decades. Additionally, the fact that

NamUs is a centralized, nationwide repository means that law enforcement officials can more

easily share information and match the unknown with the missing. The only disadvantage to the

system, Gregory says, is that it is a bit clunky and slow. Additionally, as the system is set up

right now, registered users must create separate accounts for each part of the database; in other

words, one user account is required for MP and another for UP. To address these issues, the

National Institute of Justice is currently accepting proposals for project that will significantly

upgrade the system over the next year. Another disadvantage is that law enforcement is

sometimes leery of releasing too much case information to the public, especially in situations

where it is known or believed that a crime was committed (personal communication, April 21,

2015). Some agencies still prefer to use NCIC, a database that was first created in the 1960s, is

run by the FBI, and is restricted to law enforcement agencies (Burdo, 2015).

Holism vs. Reductionism

Holism, also known as systems thinking, is about “the whole.” When approaching a

problem or a system, such as an ecosystem or a bodily system, holism looks at the big picture

and sees the entire problem/system works as a whole (Williams, 1998, p. 18). According to Orr

(2010), holism/systems thinking, “focuses on relationships among things instead of on the things


themselves” (p. 53). Therefore, systems thinking does not completely ignore the individual parts

of a system; instead, it seeks to understand how all of them work together. Reductionism,

conversely, takes an individualist approach, ignoring the whole and examining each individual

piece (Williams, 1998, p. 18).

Both approaches have benefits and drawbacks. As Williams (1998) discusses, ethical and

practical difficulties can arise when engaging in what he calls “sloppy” holism, because if

everything is seen as one, “nothing is seen as separate” (p.18). At the same time, “wholes have

properties that their elements lack” (p. 18), so a laser-focus on individual parts is no better than

ignoring them.

Prior to the development of NamUs, law enforcement—and the loved ones of the

missing—were forced to take a reductionist approach to locating missing persons and identifying

the unknown dead, going through a “slow process of checking with medical examiner's offices

one by one” and navigating “a maze of federal, state and nonprofit missing person databases that

weren't completely public and didn't share information well with each other” (Karnowski, 2010).

NamUs takes a holistic approach to the problem by keeping the records of the missing and the

unknown in one repository, where they can be cross-checked for possible matches; this is

especially helpful in situations where an individual went missing in one jurisdiction and died in

another (M. Gregory, personal communication, April 21, 2015).

Systems Development Life Cycle

According to Baltzan and Phillips (2010), the systems development life cycle (SDLC)

consists of seven phases: planning, analysis, design, development, testing, implementation, and

maintenance (p. 401). There are many SDLC models. All of them include phases for gathering

requirements, performing a business analysis, designing the system, implementing the system,


and performing QA testing (Mishra & Dubey, 2013, p. 64). There is no one “correct” model; all

of them do the same thing, but use different problem-solving approaches. The decision to choose

one model over the other is dependent on the particular situation under which an individual

project is being developed.

Ruparelia (2010) states that each SDLC model can be classified in one of three

categories: linear, iterative, or a combination of both. Linear models are sequential; each stage

automatically leads into the next, and stages are not revisited or repeated. Iterative models are

structured around the idea that the SDLC is a continuous process, and each stage will be revisited

multiple times during the life of the project. A combined model is an iterative model with a

finish line: It acknowledges that, at some point, there will be no more need to revisit any of the

stages (p. 8).

The waterfall model is arguably the best example of a linear model. However, there is

also a newer, iterative version of waterfall. Each has five steps: requirements analysis, design,

implementation, testing, and maintenance. In the traditional waterfall model, each step flows into

the other sequentially. While some “splash back” is permitted, the goal of the model is to move

through each phase and onto the next without repeating. In the iterative waterfall model, testing

and analysis is appended to the end of each phase, which theoretically provides valuable

feedback when moving into the next phase. Additionally, unlike in the traditional model, it is

expected that phases will be repeated (Maheshwari & Jain, 2012, p. 286-287).

One very popular iterative model is the spiral model; it is among the most flexible of

SDLC models (Saxena & Kaushik, 2013b, p. 118), combining the traditional waterfall model and

the prototype model (Khurana & Gupta, 2012, p. 1516). It has four phases: requirements

planning, risk analysis, development and testing, and planning the next iteration. At the end of


the risk analysis phase, a prototype is produced, which is coded and tested in the third phase,

then evaluated in the fourth phase; feedback from this iteration is used to plan the next one. The

hallmark of the spiral model is its emphasis on risk analysis and mitigation, which makes it

particularly suitable for very large, costly projects (Khurana & Gupta, 2012, p. 1515-1516).

Another iterative form of software development, the agile method, is quickly growing in

popularity. As opposed to other SDLC methods, agile does not have a comprehensive upfront

requirements-gathering process; instead, it is assumed that the customer could not possibly

provide all of the information needed to build the system, particularly the needed features, at the

beginning. Agile methods are broken up into short bursts of activity (or iterations), with a

“potentially shippable” prototype produced at the end of each phase. This allows the

development process to begin even before all of the requirements are known and the model to be

honed and perfected as the process goes along (Leau, Y. B., Loo, W. K., Tham, W. Y., & Tan, S.

F., 2012, p. 162). However, one drawback, as pointed out by B. Jones, is “Sadly, all the client

hears is, ‘I can change my mind all I want.’ There is no accountability or responsibility”

(personal communication, April 2, 2015).

Notably, on very large-scale software projects involving multiple teams, multiple SDLC

methodologies may be used. According to Das, Mahapatra, & Pradhan (2013):

It is probably unrealistic to expect all teams will follow the same process; different tools

and technologies, different business needs, and inherited process and culture from

acquisitions lead to diverse working styles and methodologies. An organization may have

teams following waterfall, iterative, and agile methods, depending on their circumstances.

Ideally, all teams in a single project would follow the same process, but in a global


supply chain scenario, even those teams may be decoupled, contributing components

with some level of autonomy. (p. 20)

Implementation Method Employed by Organization

Because it was such a massive undertaking, the NamUs project was broken up into three

phases executed over a two-year period:

During Phase I, which ran from July through September 2007, the NamUs UP

database was built; at the time, it was known as the Unidentified Decedent

Reporting Center (UDRS). At the same time, the functional and technical design

of the NamUs MP database commenced; this involved gathering information on

nationwide resources for missing persons and examining privacy laws and their

potential impact on making missing persons information public.

During Phase II, which ran from October 2007 through September 2008, the

NamUs MP database was built.

Phase III, in 2009, saw the entire NamUs system go live, including cross-

checking between the UP and MP databases to attempt to match the unknown

with the missing.

Planning

During the planning phase of the SDLC, project goals are determined and a high-level

plan for the project is mapped out. A system is identified and selected; the project’s feasibility is

assessed; and the project plan is developed. The project plan is one of the most important

deliverables from this phase, as it represents the blueprints for the project. The plan is a “living

document” that should be reassessed and, if necessary, modified as the project progresses

(Baltzan & Phillips, 2010, p. 401).


Planning Regarding Your System

In the spring of 2005, the National Institute of Justice (NIJ) held a national strategy

meeting in Philadelphia, the “Identifying the Missing Summit” to address the “silent mass

disaster” of missing persons and unclaimed decedents in America. In attendance were medical

examiners, forensic scientists, victims’ families and advocates, policymakers, and federal, state,

and local law enforcement personnel. The following issues were identified:

At any given time, there are 40,000 unidentified decedents whose remains are in

medical examiners’ or coroners’ offices or who were buried/cremated as “Does.”

American medical examiners and coroners handle approximately 4,400

unidentified decedent cases every year; 1,000 of these decedents remain

unidentified a year later.

In 2004, 51% of American medical examiners’ offices had no formal policy for

retaining records on unidentified decedents.

While it is mandatory to report missing persons cases for persons aged 18 and

younger, reporting adult missing persons cases is mandatory, and only a few

states require law enforcement agencies to prepare missing persons reports for

adults. Thus, adult missing persons cases are severely underreported.

It was determined that the most critical need was for a central database and reporting

system for unidentified decedents and missing persons, one that was open not only to law

enforcement professionals but also members of the general public (US DOJ, n.d.).


Analysis

The analysis phase of the SDLC involves gathering business requirements; creating

process diagrams; and, if applicable, performing a “build or buy” analysis for the proposed

system (Baltzan & Phillips, 2010, p. 403).

Analysis Regarding Your System

There was no “build or buy” decision to make in the case of NamUs, as no similar system

existed at the time. A few local law enforcement agencies had very small missing persons and

unidentified decedent databases, most of which were not open to the public. A few non-profit

groups, such as the Doe Network, had “national,” public websites, but these, again, were rather

small, as the groups running the sites did not have the resources to build and maintain a system

as large as NamUs. The closest system to NamUs is a database maintained by the National

Center for Missing and Exploited Children, but this site focuses only on minors, and only

missing minors, not the unidentified dead.

The National Institute of Justice, which funded NamUs, defined systems requirements by

holding a number of focus groups. “The unidentified decedents database was initially created by

the National Association of Medical Examiners (NAME), which is an NIJ grantee, with

volunteer time and effort. … NIJ has strategic partnerships with the National Center for Forensic

Science and the NAME for the unidentified decedent reporting component of NamUs and with

the National Forensic Science Technology Center for development of the missing persons

database” (NamUs.gov, n.d.).


Design

During the design phase, the IT infrastructure and systems models are designed, using

pseudo code, process diagrams, business rules, and other documentation (Baltzan & Phillips,

2010, p. 406).

Design Regarding Your System

The concept of NamUs was basic: “match the known missing with the unknown found”

(US DOJ, 2010, p. 120). However, the possible data fields that could be included for missing

persons and unidentified decedents posed a combinatorics nightmare. Meanwhile, for the system

to work properly, each database had to contain a finite number of common fields, and all users—

whether law enforcement, coroners, or members of the public—would have to follow a

consistent data entry process.

The systems’ developers focused on the fact that, despite the fact that NamUs would

contain some scientific information on things like DNA and dental records, it was not meant to

be “a repository for cataloging extensive scientific detail” but an “investigative tool” for use by

law enforcement and the public. Therefore, it was decided that the data fields would be limited to

“essential data used by medical examiners, coroners and the various forensic specialties for years

to make human identifications.” For guidance, developers used the “Best Practices Guidelines

for Identification of Human Remains” developed by The National Center for Forensic Science at

the University of Central Florida (US DOJ, 2011, p. 120). As noted earlier in the paper, the UP

database was created prior to the MP database; when the MP database was created, the fields that

were used in UP were mirrored to allow cross-checking between the two systems. There are

some differences between the two databases’ fields; for example, the MP database includes the

option to enter information on the missing person’s vehicle, something that is inapplicable to an


unknown decedent case. However, the fields were kept as consistent as possible for cross-

checking purposes. Figures 2 and 3 (O’Berry, 2011) illustrate the data models for the UP and MP

databases, respectively.

Figure 2. NamUs UP data model.


Figure 3. NamUs MP data model.

Because NamUs has both public and private components (the latter being the part of the

system that is accessible to law enforcement, medical examiners, and other authorized users

only), registration processes for both types of users had to be mapped out and permissions for

each user group established. It was determined that “to support user registration processes and

ensure the integrity of NamUs case data, the NamUs System” would be “supported by a team of

Regional Services Specialists,” or RSS’es. Among other duties, the RSS’es “support public case

entry and case validation to ensure that publically entered cases meet minimum information

requirements, and that each public NamUs MP case is confirmed with law enforcement (LE) by

validating the LE and National Crime Information Center (NCIC) case numbers” (US DOJ,

2011, p. 3-4).


Figure 4 (US DOJ, 2010, p. 34) is a screenshot illustrating the different user registration

types. Note that registration is not required to access the website and view some information,

only to obtain access to additional features.

Figure 4. NamUs user types.

Figures 5 (US DOJ, 2011, p. 4) and 6 (US DOJ, 2011, p. 22) illustrate the case-entry

process for public and law enforcement users. Note that RSS’es do not need to validate user

accounts for the general public, only accounts for law enforcement, coroners, and other users

who will have access to sensitive case information that is hidden from public view:


Figure 5. Case submission and validation for MP cases entered by the general public.


Figure 6. Registration and verification process for non-public users, such as law

enforcement personnel, case managers, and medical examiners.

Development

During the development phase, the required infrastructure is put in place (hardware and

software) and the actual coding of the system is done according to the diagrams and other

documentation from the design phase (Baltzan & Phillips, 2010, p. 408).

Development Regarding Your System

The following hardware and software was selected for the NamUs system:

A Cisco ASA Firewall, which ensures that users can access only the information

their permission levels allow.

An Apache web server utilizing Fast CGI.

Ruby on Rails was used to build the website; the language was chosen because it

is an OOP language that allows for easy maintenance and updates.

A dedicated database server and MySQL database technology; MySQL was

chosen because of its “scalability and performance.”

Red Hat Enterprise Linux servers, located in a data center with access controlled

by card readers and biometric scanners. Security updates are done daily, and are

first tested on a server mirror so as not to interfere with normal daily operations

(US DOJ, 2011, p. 17-18).

Figure 7 (US DOJ, 2011, p. 16) is the NamUs network diagram.


Figure 7. NamUs network diagram.

NamUs UP, the unidentified decedent database, was created by volunteers from the

National Association of Medical Examiners (NamUs.gov, n.d.). The missing persons database

was built by the National Forensic Science Technology Center (NFSTC, 2007, p. 13).


Testing

During the testing phase, the system is tested for bugs and overall operability. This

includes mapping out the testing conditions and parameters as well as performing the actual

testing. There may be hundreds, if not thousands, of test conditions, and all of them must be

executed, documented, and if necessary, fixed, prior to moving on to the next phase of the SDLC

(Baltzan & Phillips, 2010, p. 408-409). The testing process often overlaps with the development

phase to ensure that problems are caught and fixed right away, and as the project progresses, the

customer will get involved with the testing so that they can point out issues that might not be

clear to the developers (Saxena, P., & Kaushik, M., 2013a, p. 48).

Testing Regarding Your System

I was unable to speak with anyone who knew how the NamUs system was tested or find

any public information regarding the testing process. From the information I did gather and the

conversations I did have, I can hypothesize that a lot of emphasis would have had to be placed on

security. As I mentioned, NamUs has two levels of access: one public and one for law

enforcement and other authorized personnel only. The latter users have access to highly sensitive

case information, including information that law enforcement is purposefully holding back from

public view in MP and UP cases where a crime was committed (usually kidnapping, murder, or

both). The testing would have had to ensure that the access levels did, indeed, work to hide that

information from public view; otherwise, law enforcement officials would have never gotten on

board with this system, and their participation was crucial for NamUs to be successful.

Additionally, the cross-checking functionality of the system would have had to be tested

to ensure that it was not providing wildly unsuitable matches between missing persons and

unidentified decedents and was properly matching cases with similarities.


Implementation

The implementation phase is when the project goes live and the organization begins using

it. However, before the system goes live, an implementation method must be chosen, user

documentation must be written, and training must be provided for users. There are four methods

of implementation. In a plunge implementation, the old system is discarded immediately and

completely. In a parallel implementation, both the old and new systems are used simultaneously

until it is clear that the new system meets the organization’s needs and is free of bugs. In a

phased implementation, the new system is implemented in pieces; as it is determined that each

piece works, a new piece is added until the entire system has been implemented. In a pilot

implementation, the new system is first implemented in a select department or among a select

group of people; when it is clear that the system is working correctly and is free of bugs, it is

implemented among the rest of the organization (Baltzan & Phillips, 2010, p. 409-410).

Implementation Regarding Your System

The NamUs system was brand-new; it did not replace an existing system. Some law

enforcement agencies still have their own, local databases, and a few non-profits, such as the

Doe Network, continue operating MP and UP websites. Brand-new jobs were created and

personnel hired to support NamUs operations; currently, the NamUs staff consists of about 20

full-time employees, in addition to contract employees who hold NamUs training sessions for

law enforcement personnel around the country. Figure 8 (US DOJ, 2011, p. 1) illustrates the

NamUs organizational chart.


Figure 8. NamUs organizational chart.

The various components of NamUs were implemented in phases, with the UP database

going live in 2007 and the MP database (with full cross-checking functionality against the UP

system) being launched in 2008. After the system was fully launched and operational, the biggest

hurdle was getting law enforcement personnel from across the country to participate. They had to


be convinced that the system was secure and that it would benefit them. They also required

training on how to use the system; the National Institute of Justice set up a training program,

which will be discussed in more detail later in this paper.

Maintenance

The final phase of the SDLC is maintenance, which involves ongoing repairs,

enhancements to the system, and end user support. In some organizations, a formal help desk

may be established. There are four types of maintenance: Adaptive maintenance involves making

changes to the system in light of new business requirements; corrective maintenance involves

fixing technical problems; perfective maintenance involves enhancing and improving the

technical aspects of the system, such as processing time or changing the user interface; and

preventive maintenance involves making changes to the system to prevent problems (Baltzan &

Phillips, 2010, p. 411).

Maintenance Regarding Your System

In 2011, maintenance for NamUs was awarded via a cooperative agreement to the

University of North Texas Health Science Center (UNTHSC), which, in addition to handling the

technical aspects of the NamUs information system, provides communication and outreach

services and forensic capabilities such as DNA and fingerprint matching, forensic odontology,

and forensic anthropology services. UNTHSC handles regular maintenance and minor upgrades

on their own, but major system revamps are outsourced and awarded by bid. Currently,

UNTHSC is accepting bids for a NamUs modernization project that will, among other things,

significantly upgrade the system to add more search capabilities, make data entry of cases easier,

and allow the use of one registration instead of having to create separate accounts for MP and


UP. Bids will be accepted through May 15, 2015, and the project is expected to be completed

sometime in 2016.

Data Management – Data Backup/Disaster Recovery

In our increasingly technology-dependent society, all organizations need a backup and

disaster recovery (BDR) plan. Due to the transition from paper to digital records, electronic data

is growing at a rate of 25% per year, and one study showed that over half of all small- to

medium-sized businesses could handle, at most, a four-hour shutdown before their business was

significantly impacted (StorageCraft, n.d., p. 8-9). Another study indicated that of companies

experiencing a “major loss” of electronic data, only 6% survived long-term, 43% shuttered

immediately after the loss, and 51% shut down within two years (StorageCraft, n.d., p. 1).

The terrorist attacks of September 11, 2001, highlighted the preparedness—or, more

specifically, the lack thereof—of most businesses when faced with a catastrophic event. Prior to

9/11, very few organizations addressed terrorist attacks or acts of war in their BDR plans; after

9/11, a survey conducted by the Disaster Recovery Journal reported that 97% of respondents

admitted that they needed to revise their BDR plans (Stephens, 2003, p. 34). However, terrorist

attacks and natural disasters aren’t the only events that can trigger a catastrophic data loss; a

computer virus or a simple system malfunction could easily bring an organization to its knees

(Botha & Von Solms, p. 328). The two most common reasons for using a backup system are

quite mundane: users accidentally deleting files and recovery from a disk failure (Chervenak,

Vellanki, & Kurmas, 1998, p. 17).

Tape backups have been the tried-and-true backup medium of choice, and are still used

by many organizations today. However, tape backups are notoriously unreliable, with a failure

rate of about 70% (StorageCraft, n.d., p. 11). Post 9/11, many organizations were unable to


retrieve data backed up on tapes due to defective media or data errors (Stephens, 2003, p. 39).

For these reasons, StorageCraft (n.d.) recommends using tape backups only for “off-site vaulting,

long-term data archiving and other related uses” (p. 12).

Disk arrays are the “current standard backup choice” due to their efficiency and

reliability, and “additional technologies can make disk arrays even more effective, such as using

ultra-reliable fiber- channel style drives for the array” (StorageCraft, n.d., p. 12).

Cloud-based backup is growing in popularity. Data is stored offsite, and cloud vendors

can often provide expertise and features many organizations do not have in-house. Backing up

data in the cloud allows for “automated recovery and verification” and the use of virtual servers

or machines (VMs) that “are dynamically scaled in real-time and are available in multiple OS

configurations.” VMs can be used in conjunction with other backup options or alone

(StorageCraft, n.d., p. 12-13). Another benefit of cloud backup is that, when information is

stored in a remote, virtual server, it is not in the same area where the disaster that befell the

organization occurred, the importance of which was clearly illustrated on 9/11, when

telecommunications services in Lower Manhattan were wiped out (Stephens, 2003, p. 36).

Data Management – Data Backup/Disaster Recovery Regarding Your System

NamUs utilizes cloud-based backup, which is outsourced to Amazon through its AWS

GovCloud service. Partial system backups are run nightly, and full system backups are run

weekly on weekends or during other off-peak hours. For redundancy purposes, AWS GovCloud

stores the backup data in three separate locations (US DOJ, 2011, p. 19).

Impact of Implementation

NamUs is transforming the way in which law enforcement works to solve missing

persons and unidentified decedent cases. Through a combination of information sharing between


law enforcement professionals in different jurisdictions and crowd-sourcing efforts from the

general public, NamUs boasts the following statistics as of October 1, 2014:

20,917 total missing person cases have been reported to NamUs. 7,537 have been

closed (821 directly due to NamUs) and 10,546 cases remain active.

11,621 total unidentified person cases have been reported to NamUs. 1,471 have

been closed (381 directly due to NamUs) and 9,845 cases remain active (National

Institute of Justice, 2014).

After the full system went live, law enforcement was slow to adopt NamUs. First, the

original NamUs staff was very small, and it took time to get the word out that NamUs even

existed. Second, once word did get out, there was a need to train law enforcement on how to use

the system and convince them that the system would be of benefit to them. The latter proved to

be a challenge, and in some cases continues to be so, because law enforcement agencies tend to

not want to share information with each other; sometimes, even investigators operating in the

same unit are leery of sharing information with co-workers for fear of being “one-upped.”

Although the concept of NamUs is quite simple, the system itself is quite complex, and

there are numerous business rules to follow regarding how to enter cases, which information

should and should not be inputted for both missing persons and unidentified decedents, and how

to use the various search and case management features; the official training manual is 191 pages

long.

According to S. Pettern, shortly after NamUs went live, the National Institute of Justice

began holding training academies in various parts of the country to teach people who would, in

turn, teach others (personal communication, April 18, 2015). Progress was made very slowly.

The system launched in 2008, but by 2010, only about half of law enforcement agencies


nationwide were utilizing NamUs. However, in late 2010/early 2011, the government gave

NamUs more money to work with. More staff was hired, more training classes were held, and as

of 2015, all major law enforcement agencies in the U.S. have registered users on NamUs. There

still exist a few agencies that do not yet know about it, but they tend to be very small, and they

may not even have any missing person or unidentified decedent cases in their jurisdictions (M.

Gregory, personal communication, April 21, 2015).

Once the training classes were commenced, it was discovered that, in addition to teaching

law enforcement how to use the NamUs system, there was a great need to teach them how to

work missing persons and unidentified decedent cases, period. In some smaller jurisdictions,

these types of cases are rare. Therefore, NamUs training sessions not only include training on the

system, but general strategies for solving missing persons and unidentified decedent cases (M.

Gregory, personal communication, April 21, 2015).

As an example, the Colorado Bureau of Investigation offers a two-day, 16-hour training

class for law enforcement called "Cold Case Homicide Investigation: Strategies & Best

Practices." It's held throughout the year in various locations in Colorado. An investigator from a

coroner's office and a NamUs trainer give a presentation discussing:

How to access the NamUs public site.

How to conduct searches based on specific case characteristics.

How to obtain access to enter cases into NamUs MP.

Find out who to contact to have cases entered into NamUs UP (a function that is

restricted to medical examiners and coroners).

The various resources available via the NamUs program, such as DNA testing.


To illustrate the benefits of NamUs, a “success story” is also presented. S. Pettern

describes the success story she uses in her presentations:

I give the case history of Paula Beverly Davis. She was a young woman who went

missing from Kansas City, MO, on August 9, 1987. She was last seen at a truck stop on I-

70. The very next day, along an exit ramp on I-70, a young woman's body was found near

Dayton, Ohio. For 22 years, no one matched these two cases. Then, in 2009, Paula's

sisters, members of the public, heard about NamUs and did a search. The coroner in Ohio

had entered his Jane Doe. Paula had two very distinct tattoos that had been mentioned in

the coroner's report. In less than 30 minutes, Paula's sisters found her in the database.

"Jane Doe's" remains were exhumed, she was cremated, and she's now buried in the same

cemetery as her mother, who died not knowing what happened to her oldest daughter.

(personal communication, April 18, 2015)

The NamUs presentation lasts only about an hour; the remaining 15 hours focus on

strategies for solving missing persons and unidentified decedent cases (S. Pettern, personal

communication, April 18, 2015).

Still, despite all of NamUs’ success stories, and despite the upcoming development of

NamUs 2.0, the system remains underfunded by the government and underutilized by law

enforcement. Some law enforcement agencies remain skeptical of the value of NamUs

(especially the crowd-sourcing aspects) and participation in the database is entirely voluntary; as

mentioned earlier, some law enforcement agencies prefer the law-enforcement-only NCIC

database. “Billy’s Law,” which would “would mandate better collaboration between NCIC and

NamUs, secure funding for NamUs through 2020 and establish best practices for municipal, state

and federal law enforcement agencies” has stalled in Congress for the past five years and


attracted very little public attention (Burdo, 2015). B.J. Spamer, NamUs director of training and

analysis, told NBC Philadelphia that he believes the issue is with the general public taking an

overall negative view of the missing and the unidentified, some of whom spent their lives on the

fringes of society: “We have some victims who are involved in prostitution, drug use. As far as

we’re concerned, every one of those individuals has a left-behind family and that’s our focus”

(Burdo, 2015).

Although law enforcement has been slow to adopt NamUs, the general public—the loved

ones of the missing and their advocates across the country—have embraced the system. Thus, it

can be argued that the biggest impact of NamUs has been on these civilians; it has harnessed the

power of the Internet and crowd-sourcing to provide them with a tool to actively participate in

the process of locating their missing loved ones. NamUs is helping bring closure to these

families, one case at a time.


References

Baltzan, P., & Phillips, A. (2010). Business driven technology (4th ed.). Boston, MA: McGraw-

Hill/Irwin.

Botha, J., & Von Solms, R. (2004). A cyclic approach to business continuity planning.

Information Management & Computer Security, 12(4), 328-337.

http://dx.doi.org/10.1108/09685220410553541

Burdo, A. (2015, February 18). Missing in America: A Mass Disaster Over Time. NBC

Philadelphia. Retrieved from http://www.nbcphiladelphia.com/news/local/Missing-in-

America-A-National-Crisis-NamUs-Todd-Matthews-292456511.html

Chervenak, A., Vellanki, V., & Kurmas, Z. (1998, March). Protecting file systems: A survey of

backup techniques. In Joint NASA and IEEE Mass Storage Conference. Retrieved from

http://www.storageconference.us/1998/papers/a1-2-CHERVE.pdf

Cohen, S., Dori, D., de Haan, U., Cohen, S., De Haan, U., & Dori, D. (2010). A software system

development life cycle model for improved stakeholders’ communication and

collaboration. International Journal of Computers, Communications & Control, 1, 23-44.

Retrieved from http://visual-

process.com/docs/ASoftwareSystemDevelopmentLifeCycleModelforImproved.pdf

Das, T. K., Mahapatra, D. K., & Pradhan, G. K. (2013). Towards large scale software project

development and management. Journal of Computer Engineering, 8(6), 20-35. Retrieved

from http://iosrjournals.org/iosr-jce/papers/Vol8-Issue6/D0862035.pdf

Karnowski, S. (2010, March 8). Database can crack missing person cases -- if used. Associated

Press. Retrieved from http://phys.org/news187242170.html


Khurana, G., & Gupta, S. (2012). Study & Comparison of Software Development Life Cycle

Models. International Journal of Research in Engineering & Applied Sciences, 2(2),

1513-1521. Retrieved from

https://www.academia.edu/8608736/STUDY_and_COMPARISON_OF_SOFTWARE_D

EVELOPMENT_LIFE_CYCLE_MODELS

Leau, Y. B., Loo, W. K., Tham, W. Y., & Tan, S. F. (2012, May). Software development life

cycle AGILE vs traditional approaches. In International Conference on Information and

Network Technology (Vol. 37, No. 1, pp. 162-167). Retrieved from

http://ipcsit.com/vol37/030-ICINT2012-I2069.pdf

Maheshwari, S., & Jain, D. C. (2012). A Comparative Analysis of Different Types of Models in

Software Development Life Cycle. International Journal of Advanced Research in

Computer Science and Software Engineering, 2(5), 285-290. Retrieved from

http://www.ijarcsse.com/docs/papers/May2012/Volum2_issue5/V2I500405.pdf

Mishra, A., & Dubey, D. (2013). A Comparative Study of Different Software Development Life

Cycle Models in Different Scenarios. International Journal, 1(5), 64-69. Retrieved from

http://www.ijarcsms.com/docs/paper/volume1/issue5/V1I5-0008.pdf

National Forensic Science Technology Center (NFSTC) (2007). Annual Report 2007. Retrieved

from https://www.nfstc.org/about/annual-reports/

National Institute of Justice (October 2014). NamUs Fact Sheet. Retrieved from

https://www.findthemissing.org/documents/NamUs_Fact_Sheet.pdf

NamUs.gov (n.d.). About NamUs. Retrieved from http://www.namus.gov/about.htm


O’Berry, M. (2011). NamUs: National Missing & Unidentified Persons System [PDF document].

Retrieved from NAJIS 2011 Conference Presentations Web site:

http://www.najis.org/2011_Conference_Presentations/NamUs.pdf

Orr, J. (2010, August 12). What is “Systems Thinking”? Machine Design, 82(13), 53.

Ruparelia, N. B. (2010). Software development lifecycle models. ACM SIGSOFT Software

Engineering Notes, 35(3), 8-13. http://dx.doi.org/10.1145/1764810.1764814

Saxena, P., & Kaushik, M. (2013a). Software Development: Techniques and Methodologies.

International Journal of Software & Hardware Research in Engineering, 1(3). Retrieved

from http://ijournals.in/ijshre/wp-content/uploads/2013/11/IJSHRE_1323.pdf

Saxena, P., & Kaushik, M. (2013b). Advantages and Limitations of Different SDLC Models.

International Journal For Technological Research In Engineering, 1(3), 117-121.

Retrieved from http://www.ijtre.com/manuscript/2013010301.pdf

Stephens, D. O. (2003). Protecting records. Information Management Journal, 37(1), 33.

Retrieved from https://www.arma.org/bookstore/files/stephens_0103.pdf

StorageCraft (n.d.). Building Your Backup and Disaster Recovery Plan 101 [White Paper].

Retrieved from https://www.storagecraft.com/documents/Building-a-BDR-Plan-101-

final.pdf

U.S. Department of Justice (2010). A Guide for Users of the National Missing and Unidentified

Persons System. Retrieved from http://www.nij.gov/funding/Documents/fy11-namus-

academies-guide.pdf

U.S. Department of Justice (January 2011). National Missing and Unidentified Persons System

(NamUs) Concept of Operations. Retrieved from

http://www.nij.gov/funding/Documents/fy11-namus-conops-2011.pdf


U.S. Department of Justice (October 2014). NamUs Fact Sheet [White Paper]. Retrieved from

https://www.findthemissing.org/documents/NamUs_Fact_Sheet.pdf

U.S. Department of Justice (n.d.). NamUs Background [White Paper]. Retrieved from

https://www.findthemissing.org/documents/NamUs_Background.pdf

Williams, S. (1998). Holism, Reductionism and Communitarian Visions. Social Alternatives,

17(1), 17-20.