Here's how to do that if the code is in github:
Summary
Just add#L[STARTING_LINE_NO]-[ENDING_LINE_NO]
Example
https://github.com/angular/angular.js/blob/master/test/ApiSpecs.js#L6-16
Tuesday, September 17, 2013
Highlighting Lines of Code in Github
Ever needed to share some code with somebody and point them to the lines of interest?
Here's how to do that if the code is in github:
Here's how to do that if the code is in github:
Monday, September 2, 2013
21 CFR Part 11 and the SDLC
In this posting, I will attempt to address the challenges posed by the FDA 21 CFR Part 11, which is a law aimed at ensuring that companies implement good business practices, in their developing software efforts to meet said requirements.
21 CFR Part 11 addresses Standard Operating Procedures (SOPs), Medical Device Quality Standards Regulation (QSR), Good Clinical Practices and Good Manufacturing Practices.
The Systems development life cycle (SDLC) is a process used by a systems analyst to develop an information system, training, and user (stakeholder) ownership. The SDLC aims to produce a high quality system that meets or exceeds customer expectations, reaches completion within times and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.
Following a SLDC in order to develop a 21 CFR Part 11 regulated software application is essential because its very intent is to provide a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The SDLC describes the different stages involved in the software development project from the drawing board/planning, implementation, testing, deployment, through the completion of the project.
Project managers benefit from the process, tools and project artifacts generated as a result of following an SDLC. The project life cycle integrates the project management and SDLC cycles with the activities directly associated with system deployment and operation.
But developing software for medical devices that complies with the FDA's Quality System regulation is necessary hurtle for companies that want to compete in the medical/FDA-regulated industry.
This hurtle is not near as "complicated" as some make it seem.
It basically means that your software needs to be engineered properly with complete access control and audit capabilities.
I enjoyed over 10 years of hard core software application development prior to joining IBM.
In my first project at IBM, I researched and developed security components for SmartCard LifeCycle Management System using IBM's flagship e-business security software, Tivoli Policy Director (TPD), which allows organizations to create secure relationships among customers, partners, suppliers and employees.
I focused on enterprise-security-related software application development projects, such as:
I later transferred from IBM Global Business Services to the IBM Software group to help develop the administrative UI for the IBM Next Generation Intrusion Protection Appliance.
What always happened on those projects was the business analysts would take in inordinate amount of time to fully define everything about the system, even though none of them had any relevant software development experience, and produced a tome of a design document, which was supposed to serve as a reference for developers' requirements.
At that point, the project was always behind schedule and my team took over.
I would spend a day or two reading through that wordy tome and make my own (useful) design documents.
Next, I would find the subject matter experts (SMEs) to validate my designs and begin a series of design/implement/evaluate sessions, very much like the Agile process, but light on testing. (The need for testing, especially in a team environment that uses a constant integration (CI) server is a topic for another day :-)
The fact was that the project management office would be freaking out as the customer began to tighten the rope of leniency as they began to get concerned that the project was falling behind since they had not "seen" anything.
Process and methodology at that moment was always thrown out the door as the project manager (PM) would scream, "Just get 'er done."
The purpose of following RUP software engineering methodology is to provide a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is “use-case driven, architecture-centric, and incremental and iterative”.
Here's what a typical RUP plan would look like:
RUP was a big improvement over the Waterfall methodology, but many software development projects would still fall behind schedule, leaving PM's standing in the lurch. Then, along came Agile...
Agile provides well-defined planning events and a "time-boxed", iterative approach to development that project managers like.
The trouble with many Agile projects is that the focus is on cranking out stories (aka Use Cases in RUP parlance) and their associated features with less emphasis on code quality.
However, the 21 CFR Part 11 and the FDA, in general, is all about quality...
... and that's a problem.
A 483 is issued when investigators observe any significant objectionable conditions. FDA investigators are trained to ensure that each observation noted on the 483 is clear, specific and significant. The observations are cited when in an investigator’s judgment these conditions or practices observed indicate that an FDA-regulated target is in violation of FDA’s requirements.
http://www.fda.gov/AboutFDA/CentersOffices/OfficeofGlobalRegulatoryOperationsandPolicy/ORA/ORAElectronicReadingRoom/ucm061813.htm
http://www.fda.gov/downloads/ICECI/EnforcementActions/WarningLetters/1999/UCM067262.pdf
http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/2005/ucm075385.htm
I think it's safe to say that no business owner would ever want to receive one of those.
These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.
Quality is of utmost importance in projects that intend to meet 21 CFR Part 11 requirements.
Therefore, unless the technical resources that implement the application care a lot about the quality of their code, are seasoned enough to understand what good code means, and are willing to enforce coding standards and stand up to PM's that are always pushing to "get 'er done", the risk of delivering software that complies with FDA regulations will always exceed an acceptable level, regardless of the chosen software development methodology (and some form of agile is the way to go).
Background Definitions
21 CFR Part 11
Title 21 is the portion of the Code of Federal Regulations (CFR) that governs food and drugs within the United States for the Food and Drug Administration (FDA), the Drug Enforcement Administration (DEA), and the Office of National Drug Control Policy (ONDCP).21 CFR Part 11 addresses Standard Operating Procedures (SOPs), Medical Device Quality Standards Regulation (QSR), Good Clinical Practices and Good Manufacturing Practices.
SDLC
The systems life cycle (SLC) is a methodology used to describe the process for building information systems.The Systems development life cycle (SDLC) is a process used by a systems analyst to develop an information system, training, and user (stakeholder) ownership. The SDLC aims to produce a high quality system that meets or exceeds customer expectations, reaches completion within times and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.
Following a SLDC in order to develop a 21 CFR Part 11 regulated software application is essential because its very intent is to provide a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The SDLC describes the different stages involved in the software development project from the drawing board/planning, implementation, testing, deployment, through the completion of the project.
Project managers benefit from the process, tools and project artifacts generated as a result of following an SDLC. The project life cycle integrates the project management and SDLC cycles with the activities directly associated with system deployment and operation.
The Hurtle
The FDA recommends that application development teams take an integrated approach to their software development lifecycle (SDLC), which combines risk management strategies with principles for software validation.But developing software for medical devices that complies with the FDA's Quality System regulation is necessary hurtle for companies that want to compete in the medical/FDA-regulated industry.
This hurtle is not near as "complicated" as some make it seem.
It basically means that your software needs to be engineered properly with complete access control and audit capabilities.
Experience Matters
Since I have well over 10 years of enterprise application security software development experience and have worked with some of the most talented software engineers in the world, these requirements seem easy/natural to me.I enjoyed over 10 years of hard core software application development prior to joining IBM.
In my first project at IBM, I researched and developed security components for SmartCard LifeCycle Management System using IBM's flagship e-business security software, Tivoli Policy Director (TPD), which allows organizations to create secure relationships among customers, partners, suppliers and employees.
I focused on enterprise-security-related software application development projects, such as:
- Software Engineer I architected and implemented various design patterns for Web Identity (formerly IBM Registration) is the standard service for IBM external applications that register, authenticate, or profile external web-based customers, business partners, suppliers, and other users of ibm.com. WI performs Single Sign On, Global Session Persistence, and User Identity and Profiling and Access Control functions.
- Security Consultant Implemented IBM.COM Single Sign On (SSO) prototype for IBM’s BT/CIO office and the Tivoli PDT.
- Security Architect & Lead Developer Designed and implemented Voice over IP (VoIP) security architecture for a fortune 5 telecommunications company. System components (order entry, billing and account management ) were presented to users (customer facing and a customer service rep (CSR)) via web based portal application. Designed corporate messaging infrastructure to manage application entitlements (user creation and role management).
- Lead Security Application Developer Performed analysis, design and implementation phase of enterprise Authentication and Authorization infrastructure replacement project for fortune 5 financial corporation.
- SOA Security Architect Produced detailed SOA Security Architecture deliverable for Service Oriented Architecture Methodology (SOMA) engagement focused on contract, pricing and rebate functionality for a distributor of medical products, equipment, billing services and pharmaceuticals.
I later transferred from IBM Global Business Services to the IBM Software group to help develop the administrative UI for the IBM Next Generation Intrusion Protection Appliance.
Software Development Methodologies
Waterfall Methodology
Early in my programming career, I worked for several fortune 500 companies that followed the Waterfall software development methodology:What always happened on those projects was the business analysts would take in inordinate amount of time to fully define everything about the system, even though none of them had any relevant software development experience, and produced a tome of a design document, which was supposed to serve as a reference for developers' requirements.
At that point, the project was always behind schedule and my team took over.
I would spend a day or two reading through that wordy tome and make my own (useful) design documents.
Next, I would find the subject matter experts (SMEs) to validate my designs and begin a series of design/implement/evaluate sessions, very much like the Agile process, but light on testing. (The need for testing, especially in a team environment that uses a constant integration (CI) server is a topic for another day :-)
The fact was that the project management office would be freaking out as the customer began to tighten the rope of leniency as they began to get concerned that the project was falling behind since they had not "seen" anything.
Process and methodology at that moment was always thrown out the door as the project manager (PM) would scream, "Just get 'er done."
Rational Unified Process
Prior to joining IBM I worked at an internet consulting company iXL where we followed the Rational Unified Process (RUP) of software development.The purpose of following RUP software engineering methodology is to provide a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is “use-case driven, architecture-centric, and incremental and iterative”.
RUP Phases
Here's a high level view of what the RUP phases:Here's what a typical RUP plan would look like:
Objectives
- Improve the integrity of the commitments made by SDLC by defining the business process by which decisions are made.
- Minimize product changes (churn) once the decision is made to initiate a project.
- Define a common framework for communicating project status in terms of business commitments
- Enforce appropriate minimum standards on entry and exit criteria for each applicable project lifecycle phase.
- Define milestones for project process metrics: Cycle Time & Quality
RUP was a big improvement over the Waterfall methodology, but many software development projects would still fall behind schedule, leaving PM's standing in the lurch. Then, along came Agile...
Agile software development
In 2001, the Agile software development methodology became popular, which is based on the Agile Manifesto:
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
Agile provides well-defined planning events and a "time-boxed", iterative approach to development that project managers like.
The trouble with many Agile projects is that the focus is on cranking out stories (aka Use Cases in RUP parlance) and their associated features with less emphasis on code quality.
However, the 21 CFR Part 11 and the FDA, in general, is all about quality...
... and that's a problem.
Some Software requirements for 21 CFR Part 11
- System validation to make sure performance of the system is accurate and reliable.
- System should be able to produce accurate/complete record copies that are readable both in human and electronic forms.
- Record protection to ensure they are accurate and able to be retrieved easily.
- System access should have strong controls to prevent unauthorized access.
- Must have time stamped audit trails.
- Operational system checks must be in place to ensure proper sequencing of steps and events.
- Authority checks must be in place to make sure that only the authorized personnel can get into the system.
- Proper controls on system documentation
- Complete and accurate record retention practices
- Written policies must be produced that hold everyone accountable for any actions via their electronic signature.
Other Systems Impacted By 21 CFR Part 11 Requirements
- Employee Training
- Document Management
- Change Control
Out of Compliance
If you get audited and found wanting, you will get a 483 (FDA violation) citation.A 483 is issued when investigators observe any significant objectionable conditions. FDA investigators are trained to ensure that each observation noted on the 483 is clear, specific and significant. The observations are cited when in an investigator’s judgment these conditions or practices observed indicate that an FDA-regulated target is in violation of FDA’s requirements.
Example 483 violations
http://www.fda.gov/Food/RecallsOutbreaksEmergencies/Outbreaks/ucm224855.htmhttp://www.fda.gov/AboutFDA/CentersOffices/OfficeofGlobalRegulatoryOperationsandPolicy/ORA/ORAElectronicReadingRoom/ucm061813.htm
http://www.fda.gov/downloads/ICECI/EnforcementActions/WarningLetters/1999/UCM067262.pdf
http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/2005/ucm075385.htm
I think it's safe to say that no business owner would ever want to receive one of those.
Summary
All projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost". These are also referred to as the "Project Management Triangle". You cannot change any one constraint without affecting the other two.These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.
Quality is of utmost importance in projects that intend to meet 21 CFR Part 11 requirements.
Therefore, unless the technical resources that implement the application care a lot about the quality of their code, are seasoned enough to understand what good code means, and are willing to enforce coding standards and stand up to PM's that are always pushing to "get 'er done", the risk of delivering software that complies with FDA regulations will always exceed an acceptable level, regardless of the chosen software development methodology (and some form of agile is the way to go).
Sunday, September 1, 2013
lexsheehan.blogspot.com has over 25,000 page views!
Started blogging less than a year ago and now have over 25,000 page views ...
Thank you for reading my stuff!
Lex
Thank you for reading my stuff!
Lex
A Predictable Reaction to a Software Development Estimation with Full Disclosure
Here was my response:
If your question is how "hard", I'd say "not hard".
If your question is how much would it cost and how long would it take? ... then how "hard" it is depends.
As you know, delivering software involves the interaction between business policy/process, data, technology and people.
Consider:
1. Is the algorithm for determining the scores well defined?
(Would the question/answer > bucket be provided in the form of a spreadsheet file (or would the programmer be given written descriptions and have to type everything in from scratch?)
2. How much flexibility is there on the final graph image?
(Looks like they have created a whole lot of static images, one for each possible answer. Another solution would be to have a javascript driven/dynamic graph, which would likely be the way I'd lean.)
3. Are you storing the results or simply generating the resulting score for display on the web site at the end of the survey?
(This is a big one. If the answer is just generate the answer and not record anything, other than possibly an email then this could all be done in javascript, i.e., in the web browser...no backend database required.)
4. Is deployment infrastructure in place?
(Do you have a server for this application to run on already?)
5. Is this part of a bigger solution?
(Need to integrate this with other systems? Do you need to share the responses or "customers" with other systems? Do you need to automate emails to these customers? Etc.)
6. How engineered does the solution need to be?
(Most apps are developed using and agile methodology, which requires a continuous integration server that monitors for code updates, validates that new coded does not break the build, which implies all work has test code (unit, functional, integration)... I would not think this would not require multiple developers, which greatly simplifies things.
7. How many change requests will be involved?
(Will the user acceptance testing be reasonable or will there with a lot of "I know that's what you thought I said, but I was thinking of something more like this here...So, do it over, again."
8. Has a technology and/or development toolset been pre chosen?
(Does it matter what language is written in or what tools are used to develop the web app?)
[SUMMARY]
The result you get when developing software is largely dependent on the team doing the work.
I would say you're looking at any where from 4 hours to 4 weeks [or more], depending on your answers above, whether requirements will change and the experience of who's doing the work.
... [ some discussion of cost ] ...
I also included one of my favorite comic strips:
Response to full-disclosure-estimation
I think I have figured out how to do this through excel.
Subscribe to:
Posts (Atom)