Am working for a Medical devices company and we are trying to use Static code analysis tools for our development.Can somebody help us in validating whether Visual Studio 2012 Code Analysis feature is complaint to FDA or not?
I believe TFS can be validated for FDA Compliance for Static Code Analysis and other requirements depending on your QSIA Intended Use. As mentioned in OP's comment the key is validating how you are using a tool, not whether it is validated "out of the box". I believe you must validate that you have configured and use static code analysis in a way that is compliant. Just having a tool doesn't make its output automatically compliant (unless there is a "FDA-compliant" setting that cannot be disabled :-)).
Food and Drug Administration (FDA) Compliance with Visual Studio 2010 (MSDN whitepaper by Northwest Cadence, June 2011)
has an extensive walkthrough of TFS features mapped to FDA compliance and FDA document "General Principles of Software Validation". Static code analysis is specifically mentioned. Here is the relevant excerpt:
Static Code Analysis
The static code analysis in Visual Studio 2010 has several hundred rules that check code for potential code errors in several areas, which include design, naming, reliability and security. These rules can be combined into rule sets that allow only a specific subset of the rules to be run, highlighting potential problems. These range from the “Minimum Recommended Rules," which focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors, to the “All Rules” set. which contains every available rule. It’s very easy to configure a custom rule set to focus your code analysis specifically toward your needs.
There may be other references that are (or will be) relevant. Try following search keywords: TFS FDA (or better yet use +TFS +FDA to force major search engines to have both terms). +VS +FDA might return other relevant results especially if you are looking specifically for code analysis rather than overall compliance for eSignature and other Part 11 requirements.
Please vote if you found this helpful. Thanks! -Zephan
VS2012 is not compliant to FDA
Related
I've been using VS Code for a year or so now. I have no idea how VS Code Extension security is handled.
I'm alarmed by things like this:
Markdown Preview Enhanced (927K+ downloads)
Markdown Preview Enhanced (fork that points to the original repo) (2k+ downloads)
Some questions I have are:
What does Microsoft do to ensure Extensions we install are safe?
Are they scanning the Extensions for known vulns?
Is VS Code safe to use in an Enterprise Environment?
How can I tell?
Why are duplicate extension names allowed!
There are security and marketing implications by Microsoft allowing "package-squatting".
Does anyone have insights to share regarding VS Code Extension Security?
Hm. Unfortunately, the link to "extension marketplace terms" that #jonrsharpe provided does not include the word "extension". If you extrapolate VS Code Extensions to be covered by the Azure Marketplace terms (as alluded to in the text), then you get this little tidbit:
https://azure.microsoft.com/en-us/support/legal/marketplace-terms/
Publisher Privacy Policies. Publishers are responsible for providing
privacy statements that describe their privacy practices with respect
to Customer Data collected by their Offerings or any customer
information that they receive from Microsoft. Unless indicated
otherwise in connection with a Marketplace Offering published by
Microsoft, Microsoft’s privacy, security, and data location and data
retention policies will not apply to any Marketplace Offering or to
Publishers’ use of any Customer Data or other customer information.
In short "...Microsoft's privacy, security...policies will not apply to any..." VS Code Extensions OR to "...Publishers' use of any Customer Data or other customer information."
Microsoft does NOT handle VS Code Extension Security.
I curious of what you’re experiences are one the user of site definition compared to feature stapling. In a video on Channel 9 Ted Patterson explains that feature stapling is the way to go. It would be nice to know of some experiences other SharePoint experts have.
Are you all using Feature stapling or are there areas where Site Definitions is a better choice?
For me it purely scenario dependent Feature stapling is good if we have to work on some existing site definition like third party or OOTB. but if its a custom solution or my own custom product based on SharePoint i would still like to go with site definitions
Ideally, we should avoid using Site Definitions and use Features for all the custom development/provisioning/customizations cause they are much more flexible & extensible.
I have worked for Microsoft on many sharepoint projects including the 2007 and 2010 version of the http://www.microsoft.com/sharepoint public iste and almost all the customizations and provisiong was done via Feature Staplers.
If you have lots of customizations, then site definition is the only route to go.
In my experience, it's hard to maintain a complex site definition. The best way to go is create a very minimal site definition than staple the features you need. It also promotes modularity (by using features) and reusability.
I went to the Microsoft Visual Studio 2010 launch event in Minneapolis yesterday and was slightly surprised by how much they were trotting out SharePoint and improved SharePoint development in Visual Studio 2010.
SharePoint is something I've largely ignored over the years as a web developer and solution architect on a small development team. I was always under the impression that SharePoint was used mostly for intranets in large corporations, and that if you were developing for SharePoint, it meant that a corporate decision had been made to use it and you as a developer probably had few (if any) options.
I realize this assumption is probably incorrect. So, what are the "cool" uses for SharePoint? What unique business problems have you solved using it? What could make a developer excited to be working on something for SharePoint?
Document libraries in a Microsoft environment. There are many nice out-of-the-box features for managing documents.
Intranet sites that have permissions setup in such a way to allow business entities to control use of the site within their group.
Project requirements lists. List in SharePoint can be customized to some degree without ever programming.
As a conclusion so far, SharePoint is a blessing and a curse. It has a lot of value-adds, though anything outside that box is difficult change, but there are indeed many 'hooks' to do just that. WSS3.0 is free for Windows Server 2003, as is SP 2010 Foundation for Server 2008, so you can get quite a bit out of that without upgrading to MOSS or 2010 equivalent.
It's probably best used in intranet/extranet scenario's, true. There's many public facing internet sites built on it as well, if you find that cool :)
See http://www.topsharepoint.com/ (I built one of the top-10 sites ;)
It's definately not the best web content management platform but it is not bad and companies like people who have learned to manage their intranet to be able to seamlessly do the same for the internet site.
Personally I find it "cool" that I can deliver functionality quickly and without building the world from scratch (I've built enough document management solutionettes and prefer not to do it ever again). But if I have to custom build there's many footholds for customization and all of the .NET platform is available. There's workflow solutions that allow business users to customize their own workflows and not bug me with them. I'm sure there's plenty of other solutions out there that can do something similar but the integration with Microsoft Office and the rest of the Microsoft world is quite good IMHO.
I don't understand the antagonism against SharePoint and find it's mostly fueled by ignorance and people trying to use the platform for something it wasn't meant to do (like being a relational database). You will have to learn it; it's not like adding ELMAH to your project, it's a really big layer in your architecture.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to wrap my head around SharePoint. Why is it good? Why is it bad?
At a glance it appears to offer some incredible collaboration tools. However, the cost looks astronomical and it seems to be rigid & difficult to customize.
To those who've worked with SharePoint; please describe something good and something bad about it.
Pros:
Document management is its most well-known
function and integrates extremely
well with Office 2007.
Create group calendars that can be
overlayed onto your personal Outlook
and managed on the web.
Notifications in response to certain
actions on the group website
Wiki-type functionality with full
integration into the Office stack.
Full database backend which gives
you the reliability and safety of a
true RDBMS.
Extremely customizable if you choose
to develop custom websites using
ASP.NET (not the built-in wizard/gui
editor).
Form-data collection
Cons:
Freebie version is somewhat limited
on customization.
How to handle multiple editors to a
single file is not obvious.
Workflow for offline editing of
documents is non-obvious.
Very steep learning curve to use it
the right way.
Getting people to use it is like
getting people to go to the dentist.
Out-of-the-box templates don't do a
lot.
Customizing without writing code
really limits your options.
Integration with older versions of
office is ugly
Mac integration is non-existant (has
this changed recently?)
It has pretty good Office 2007 integration. As an example, Excel understands when you have a file checked out and will let you check it in (with comments) when you close it. The document management features simplistic version control (although it's not required; you can go with a single version for each file).
In SharePoint, everything is essentially a list internally and it's very easy to create a custom one. On a related note, I haven't used either yet, but it supposedly works well with workflows and InfoPath.
On the downside, it's pretty much a resource beast. It requires multiple machines with powerful specs, particularly if you want to "really" use it for document management and to be the backbone of your intranet/internet site. It scales to an extent, but it's not pretty from my vantage point.
Customizing it presents it's own challenges. You really need people focused on it full time, as both administration and customization require their own impressive learning curves.
Lastly, some of the out of the box parts are poorly implemented. The wiki is a prime example; it's basically useless in my opinion. So one thing to keep in mind is that some may consider SharePoint as a whole package as "best in class" (not saying I do!), its individual features often are not.
Good
Out of the box, it offers a ton of functionality and power, even for the stock web parts. Just creating a library of documents that anyone can open/edit/upload to is simple...even for those non-web-savvy amongst us.
Bad
Pretty much everything else.
The "Discussion Board" is a glorified Outlook email chain.
The disconnect between achieving similar results in SharePoint Designer 2007 and using the web interface are jarring and annoying
Attempting to customize the look and feel of a SharePoint site usually ends in complete disaster. Especially with WSS 3.0.
The nickel & diming scheme between the WSS 3.0 and MOSS 2007 tiers is absolutely painful; WSS 3.0 is just barely functional enough to be extremely frustrating to use
Changing MS styles is almost impossible due to their horribly-laid-out and obnoxiously large CSS file.
IT IS 2009...GET RID OF THE TABLES FOR NON-TABULAR DATA ALREADY!
It's a beast to use. And handing two complete rebranding projects for two totally different areas of the company is driving me to the point of a nervous breakdown. Especially when opening the core.css file occasionally results in all the styles I've redefined getting reset to the defaults. Without anything done by me other than just OPENING the file. And there is no ability to undo these changes.
Good thing: Great communication tool. Instead of sending out a company wide email you can post an announcement to your SharePoint site. Users can subscribe to an RSS feed of the announcements or have a email alert sent to them when the list is updated.
Bad thing: Error messages displayed on a SharePoint site are generic and the link to help resolve the issue rarely is of any help.
Good:
It can be a great collaboration tool. Beginning developing for sharepoint is simple, assuming you are familar with ASP.NET webparts.
Bad:
The development lifecycle isn't fully implemented. There are no built-in facilities for testing, among other things.
SharePoint is evolving and becoming a better collaboration tool for Microsoft Office environments. It plays well in a small to medium sized business setting. It is critical to implement “best practices” on setup; otherwise it will quickly become a nightmare to maintain and to use.
For “best practices” here are two books that I recommend for SharePoint 2007:
Essential SharePoint 2007
Sharepoint 2007
A lot of the cool things in Sharepoint are avaialable in Windows Sharepoint Services 3.0, which is free with windows server 2003/2008. All you need extra is a license for SQL Server 2000 and later, which most mirosoft shops have. In WSS you can do document management, workflows, custom sites, blogs, wiki's, etc.
If you need Excel Services, Forms Server, CMS, or some of the other MOSS features, then that's another thing. And yes, it does cost a lot of money, but it' cheaper than doing it from scratch in most cases.
Pluses:
- Great object model.
- A lot of good features just come out of the box.
Minuses:
- Steap learning curve to do things the right way.
- It's very easy to hang yourself by doing things the wrong way.
- Debugging and deployment is about as pleasurable as root canal.
good :
A lot of things can be done. Wokflowks, InfoPath forms, Excel Services, Business Data Catalogs and etc.
Bad :
You won't be able to do these described easily. Must have sharepoint administrative and development skills for good solutions that don't improve quickly.
If you have a license for Microsoft Server 2003 then you can install the standalone version of Sharepoint for FREE!
Download Sharepoint
The install is very simple when using the internal database.
Microsoft Office Sharepoint Designer 2007 is a must have for any customization.
I have created a couple Company Intranets using Sharepoint and have been very pleased with its features.
Microsoft Office 2007 interfaces nicely with sharepoint.
I have found Sharepoint to be very powerful and easy to learn. There are lots of people developing sites using sharepoint. The level of customization is awesome. The simplest customization is done in your browser, the next level is using Microsoft Sharepoint Designer 2007, and finally using Visual Studio to create new apps(webparts).
Are there any blogs, guides, checklists, or controls we should be using to ensure our SharePoint implementation is accessible?
Preferrably to the W3C double A standard, or as close to that as we can get.
We're implementing an extranet solution.
This study has already been funded by Microsoft, and unfortunately the results only seem to be online in a Word Document.
The document is hosted on this blog:
http://blog.mastykarz.nl/best-practices-for-developing-accessible-web-sites-in-microsoft-office-sharepoint-server-2007/
And the path to the document is here:
http://go.microsoft.com/fwlink/?LinkId=121877
I'm unsure on whether it would be a good thing to copy the contents of that into here to fully answer the question in a way that will be indexed by search engines, but I'll play safe as it's not my content.
The best place to start is the Accessibility Kit for Sharepoint. With this, you may reach single A standard, but in my experience, you will find it very tough to reach AA.
Microsoft didn't factor in accessibility in Sharepoint, and even 2007 suffers from a huge overdependence on table layout.
Good luck!
How are you deploying the implementation? Is it as an Intranet, or, is it as a public facing website.
I think one of the first rules is to be extremely selective with the use of out of the box web parts. Many of the web-parts I looked at weren't compliant even on a basic level.
Andrew
The best way is to run checks as you develop so you know where your pain points are.
The next step maybe to start with a minimal masterpage so you can choose what elements are presented to the user.
More advanced you can override the render methods to remove or change bits of the page that are not compliant with your checks. EG changing the case of tags (XHTML does not like all caps)
A bit more in this guide.
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
I recently read the MOSS book by Andrew Connell (www.andrewconnell.com) and it has a chapter dedicated to accessibility and SharePoint sites.
Simply put SharePoint sites are very difficult to generate W3C AAA standards, but the Accessibility Kit is one of the best starting points.
Stronly recommend his book for this chapter (http://www.amazon.com/dp/0470224754?tag=andrewconnell-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470224754&adid=18S6FKQJR5FZK56WHH6A&)
It depends how much of Sharepoint out of the box you are intending to use. In implementing our public facing site we managed to achieve AA compliance, although the amount of custom development required has raised questions over the benefits we are actually gaining from using Sharepoint in the first place.
A few pointers:
We made heavy use of SPQuery/SPSiteDataQuery to render site data to screen using xslt which gave us full control over the output. I found this link helpful:
http://blog.thekid.me.uk/archive/2007/02/25/xml-results-using-spsitedataquery-in-sharepoint.aspx
Check out RadEditor for Sharepoint for a nice accessible rich text editor for publishing.
For xhtml compliance, things were a little more tricky, we had to override most of the Sharepoint publishing controls' render methods to correct dodgy output.
If you are wanting to leverage the portal like capabilites of Sharepoint in your extranet it is more problematic. The web part framework is not accessible and I have not yet found a way to make it so. Any suggestions welcome!