About Debra Fryar

Debra is a retired government employee, having received the Defense Logistics Agency Distinguished Career Award in 2008. As a former Department of Defense employee, she specializes in data and project management and has extensive experience in program management and eCommerce system development and deployment. Today she does Business Development and Marketing for Partnet, Inc.

Why Doesn’t the Government Use OpenOffice?

From time immemorial, people have complained about wasteful government spending. Congress is continually looking for programs to cut and budgets to reduce, yet we continue to spend millions of dollars on software we could get for virtually free. Take Apache OpenOffice for example. Apache OpenOffice is the leading open-source office software suite for word processing, spreadsheets, presentations, graphics, and databases. It is available in many languages and works on all common computers. It stores all your data in an international open standard format and can also read and write files from other common office software packages. It can be downloaded and used completely free of charge for any purpose.

According to Bureau of Labor Statistics, today there are over 22 million people employed by federal, state and local government in the United States.  Microsoft Office 2016 Professional retails at $399.00 in the Microsoft store. To upgrade everyone to the latest software package, it would cost $8.8B. Sure there are discounts for buying in bulk but even at %50 off, it would cost  over $4B. To upgrade to the latest OpenOffice software, it would cost ZERO in software. Just by making this one software decision, State, Local and Federal government could literally save billions.

Sure there are some costs required for installing the software and training the employees. Every organization what conducts migration to OpenOffice.org faces with the opposition of existing users who settle down to other office suites and don’t want to change their habits. But training is an ongoing cost anyway since new employees are continually entering the workforce and the current office suites are continually changing their software.

In Europe, over the last 10 years there has been a grass roots transition to OpenOffice. Many city governments […]

FBI Public Service Announcement Warning of IoT Apps

Earlier this month on September 10, 2015, the FBI put out a Public Service Announcement (PSA) entitled “Internet of Things Poses Opportunities for Cyber Crime.” warning companies and the general public to be aware of Internet of Things (IoT) vulnerabilities cybercriminals could exploit and encourages the use of strong passwords. The PSA included the following example:

Cyber criminals can take advantage of security oversights or gaps in the configuration of closed circuit television, such as security cameras used by private businesses or built-in cameras on baby monitors used in homes and day care centers. Many devices have default passwords cyber actors are aware of and others broadcast their location to the Internet. Systems not properly secured can be located and breached by actors who wish to stream live feed on the Internet for anyone to see. Any default passwords should be changed as soon as possible, and the wireless network should have a strong password and firewall.

The FBI identifies these IoT devices:

Automated devices which remotely or automatically adjust lighting or HVAC
Security systems, such as security alarms or Wi-Fi cameras, including video monitors used in nursery and daycare settings
Medical devices, such as wireless heart monitors or insulin dispensers
Wearables, such as fitness devices
Lighting modules which activate or deactivate lights
Smart appliances, such as smart refrigerators and TVs
Office equipment, such as printers
Entertainment devices to control music or television from a mobile device
Fuel monitoring systems

The FBI recommends the use of “Strong Passwords” to secure these devices.  According to the traditional advice — which is still good — a strong password is:

Has 12 Characters, Minimum: You need to choose a password that’s long enough. There’s no minimum password length everyone agrees on, but you should generally go for passwords that are […]

By |October 6th, 2015|Security|0 Comments|

Why Security and Development staff should work together

In many large companies and even small ones, the application development staff and the security staff do not generally work together on a project team. The developers see themselves as architects and creators of an application, making sure it does what the customer wants.  The security folks often see themselves as more of a compliance role, testing code after it is developed and making sure it is protected on the network. Security also has the reputation of telling folks what they “can’t” do rather than helping the developers make good security decisions.

Unfortunately this scenario is very true in many companies. Code could be developed in a more secure fashion if the developers and security staff worked as a team rather than as adversaries. When developing code, you end up with both bugs and design flaws. Bugs can be caught in testing using a variety of software tools. Flaws in the design and architecture of an application are harder to identify and are responsible for 50 % of security defects.

By encouraging the team to include security in the initial design of the product and putting security first, many design flaws can be avoided. Gary McGraw and Jim DelGrosso of Cigital, Inc. believe adding an architecture risk analysis process has proven to be useful in finding and fixing flaws. They recommend starting the process with an architectural diagram.  With the architecture diagram in hand, they undertake three specialized analysis steps:

1) Known-attack analysis – Take a list of known attacks relevant to your architecture and go through them. Microsoft’s STRIDE approach (part of what they mistakenly call threat modeling) is a good example. STRIDE is an acronym for spoofing, tampering, repudiation, information disclosure, denial of service, and […]

By |September 28th, 2015|Security|0 Comments|

There is an “I” in Security

There has been a lot of discussion in the news lately about cybersecurity threats and big company security breaches. These cases are really scary and should result in consequences for the people involved, but a lot of security comes down to personal responsibility. There is an “I” in security.

I need to make sure I password protect my laptop, tablet and cell phone.

I need to make sure I don’t share my password with others or write it down on a piece of paper that can be easily discovered.

I need to make sure I don’t leave my work station while logged into sensitive corporate data.

I need to make sure I read that email and verify it is from a trusted person before I open that attachment.

I need to pay attention when clicking on links that appear to be sent from my bank.

I need to remember that NO reputable institution such ask my bank, the IRS, FedEx or Facebook would ever as me to provide personal information or my password.

No matter how good my firewall, spam filter, or antivirus software is, there is nothing in the world that will protect me from a momentary lapse in judgment as I use my computer. Everyone needs to have frequent education and training on how to keep you safe. There are SO many ways that security can be compromised by literally inviting malware or viruses onto your computer. We need to be vigilant and constantly think about what we are doing as we use our computer systems and mobile devices both at work and at home.

It is hard to admit it but I might just be the weakest link in my security system.

By |August 20th, 2015|Security|0 Comments|

Patient Verification vs. Identity Fraud

A recent article in the Healthcare Info Security discusses a study conducted by the Ponemon Institute, sponsored by Experian’s ProtectMyID. The study asserts that nearly 70 percent of the medical ID theft incidents involved others fraudulently using credentials to obtain healthcare services. In more than half of the medical ID theft cases, the victims didn’t report the incidents to law enforcement, often because they knew the person who stole their identity.

This is often called the “Robin Hood effect” because family members are allowing the use of their insurance card to cover uninsured relatives. It is understandable why someone might help out an ailing relative, however, cases have been found where cards were used to purchase medical devices and equipment like scooters that were later sold on eBay.

The Affordable Care Act estimates that healthcare reform could bring coverage to 30 million uninsured who lack coverage. By covering more people with healthcare, we should see a substantial drop in the number of uninsured but will we see a corresponding drop in medical ID theft? That may be optimistic.

That’s because not all health insurance policies are created equal. Some of the least expensive new offerings expected to be obtainable on the market, or provided through the expansion of state-level Medicaid and Children’s Health Insurance Programs, might not offer all the benefits someone wants, Ponemon says. There could still be a motivation to fraudulently gain access to better polices which have more benefits.

One way to deter medical identity fraud is to add advanced technologies like biometrics to insurance cards. The biometrics would be used to verify the identity of the patient at every visit and would prevent fraudulent use of the insurance plan. Biometric identification would also support […]

  • Permalink

    The use of Kanban to support a well defined Software Development Life Cycle

The use of Kanban to support a well defined Software Development Life Cycle

In our last blog I discussed how the Scrum process supported the Software Development Life Cycle. Partnet uses two different proven Agile development methodologies for development: Scrum and Kanban. A specific method is chosen based on the nature of the work.

Scrum: Used for complex projects where increments of work can be flexibly managed and assigned into sprints. Work assigned within a sprint can be completed without disruption.
Kanban: Used for less-complicated projects (e.g., Problem Reports) where priorities frequently change.

Kanban is a backlog-pull model that emphasizes just-in-time delivery of work and avoids process bottlenecks by limiting in-progress work. Kanban also allows for customer-driven prioritization as tasks are regularly prioritized to match their current needs. This means that if an emerging requirement suddenly takes precedence over existing priorities, the team can flexibly respond without affecting project goals or progress. Kanban uses the same Delivery Team roles and responsibilities employed in Partnet’s Scrum process. Partnet employs Kanban for Problem Report work since this work is often subject to shifting priorities.

Partnet’s Kanban process pulls new requirements from a Customer prioritized backlog. Tasks are created and assigned to release versions based on these priorities. The process defines a series of work queues that simultaneously identify the current status of a given development task, and the assigned resource.

Together, the work queues establish a linear workflow for completion of assigned development tasks, as shown below.

 Work Queues and Linear Workflows

Work Queue

    Assigned Resource

To do
Backlog task; not actively being worked on by any project team member

Needs Requirements
Undergoing requirements analysis to define new functional requirements; assess impact to existing functionality
    Requirements Manager

Ready for Development
Requirements analysis complete or not needed


Development in Progress
Development and integration underway; includes unit testing and code reviews

How Scrum supports the Software Development Life Cycle

Last month I did a blog series on the importance of having a well define Software Development Life Cycle. Today I am going to talk about a methodology which supports the Software Development Life Cycle to keep it on track and humming.

Scrum is an iterative software development framework that employs time boxed “sprints” to deliver software quickly and incrementally. Scrum’s short development cycles offer flexibility to react to change by demonstrating functionality at the end of each iteration, promoting frequent customer interaction, and having the customer as part of the team. Scrum is used for larger efforts where work can be prioritized in batches, with each batch being of a scope and complexity such that it can proceed uninterrupted.

A Scrum team is made up of a number of players with differing roles and responsibilities.


Scrum Master
Enforces adherence to the Scrum methodology. Responsible for removing impediments for the Delivery Team. Ensures project objectives are met while balancing constraints, budgets, schedules, resources, and risk.

Delivery Team
Responsible for delivering the work. The team is made up of the following roles:

Product Owner: The voice of the customer. Has the responsibility to deliver a successful product in terms of vision and features. The  Project Lead would be the ideal person to fill this role.
Requirements Manager: Elicits, refines, and manages the solution requirements
Architect: Defines the architecture and technologies employed by the software solution
Technical Lead: Oversees software design and development
Developer(s): Codes and integrates the software
Software Test Engineer(s): Validates the software against solution requirements; enforces applicable quality standards and documents identified defects
Configuration Manager: Stages and deploys software changes to Development, Staging, and Production environments
Data Architect: Defines data architecture and allocation of data assets
Database Administrator (DBA): Maintains database; manages data access, import/export processes, and migration […]

Improve Cybersecurity with Continuous Monitoring

Cybersecurity has now superseded terrorism as our country’s #1 threat. Can continuous monitoring save the day?

  • Permalink

    Part 5: System Development Life Cycle – Release Planning and Deployment

Part 5: System Development Life Cycle – Release Planning and Deployment

The Release Planning and Deployment stage begins upon completion of software testing. During this time, no changes to the software are permitted excepting those explicitly directed by the Customer. Release Planning and Deployment is performed in three phases: Pre-deployment, Deployment, and Post-deployment


The Pre-Deployment Phase addresses three major tasks simultaneously:

Release Planning
Training and Documentation
User Acceptance Testing (UAT)

In most cases, software deployments to the System Users will be transparent to end users.

However, careful release planning and coordination is essential for ensuring that the Customer is consulted on all new or altered code and the decision to release it. Release planning also includes identification of active and standby resources, as well as specification of a roll-back strategy in the event it becomes necessary to revert or roll back the deployed code.

Partnet will collaborate with the Customer and any associated Change Control Board (CCB) representatives to create a release deployment plan, to include:

A cutover schedule, identifying the date and time for the release.
A listing of the features and/or problem reports that will be contained in the release.
Identification of a release coordinator.
A release impact assessment, including impacts to integration partners.
A roll-back plan, outlining a contingency process for removing new changes should it become necessary.

The following tasks can then be performed as part of the pre-deployment phase:

Identify the deployment team, including: Release Project Manager, Change/Configuration Manager, Database Administrator, Technical Lead, Software Test Engineer, End User Tester
Prepare a draft deployment schedule which:

Chronologically outlines required deployment tasks and estimates, including tasks to be performed by external third parties.
Identifies the complexity, timeframe, and task owner of each deployment task.

Execute a mock deployment on the Staging environment, which allows the team to rehearse deployment tasks and validate estimates.
Execute the roll-back plan on the Staging environment […]

  • Permalink

    Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Agile best practices recommend overlapping development and testing cycles. This helps identify and resolve software defects early, while minimizing scenarios where developers are simultaneously trying to fix old bugs and build new features.

Overlapping development and testing cycles also promotes the incremental delivery of working code. This process allows new features and bug fixes to be rapidly promoted, while allowing the Customer to review new features as they are developed, and make decisions about when specific features are ultimately deployed to Production.

Partnet’s software development process is enhanced by the incorporation of continuous delivery methodologies. Continuous delivery is a collection of techniques designed to improve and automate software delivery. These techniques include:

Continuous delivery pipeline
Automated testing
Mainline development
Continuous integration

Continuous delivery allows software to be developed to a high standard, easily packaged, and rapidly deployed to the various environments. Additionally, new features and bug fixes can be rapidly promoted to the Production environment with minimal risk and overhead.

Our developers use a continuous delivery pipeline to implement continuous delivery principles.

The deployment pipeline is like an automated assembly line which the code passes through to ensure it is ready for Production. This assembly line includes:

Building the software
Running unit tests
Building the application deployment
Running automated User-Interface (UI) tests

This method allows functional software to be rapidly promoted to non-Production environments for Customer inspection; or promoted directly to Production in cases where a feature or bug fix is immediately required.  For projects employing the Scrum process, this cycle repeats within each sprint until the Product Owner signifies all requirements have been met and the feature is Production-ready

Automated Testing

Automated testing requires close interaction between software developers and test engineers. The following process is employed within each development cycle (Scrum or Kanban):

Test engineers write test outline(s) for […]