I am looking for a free software tool (or set of tools) to automate the document generation that requires the IEC 62304 and the FDA V&V standards (Software of Medical Equipments).
Basically, to maintain traceability between different documents, issue/bug trackers, SVN, source code, test cases, etc., report generation, document version control, project tracking, auditory functions, etc.
The Regulatory Documentation Manager (RDM) is a set of templates and python scripts which are designed to help automate IEC62304 compliance as much as possible. At its core, IEC62304 is all about using best practices to build high-quality software that has considered and mitigated as many risks as possible.
The stated design goals of RDM are:
Provide a generic template that covers common use-cases but is customizable.
Provide readable documents; e.g., other 62304 templates include many short deeply nested sub-sections. We use a maximum of two levels of nesting. We also provide flags (e.g., for different safety classes) that prune out irrelevant parts of the document, so that the documents only include what is necessary for the particular project.
Focused on software developers; the plan documents are intended to read and used frequently by the software developers on the team. Thus, wherever there was a tradeoff between making it easy to read for developers vs regulators/auditors, we optimized for developers. For example, we re-order IEC62304 sections to follow a more logical order for developers at the cost of being less parallel to IEC62304's structure.
Easy auditablility. In order to make it easier for regulators/auditors to read the document, we include auditor comments and links back to IEC62304. These links and notes are hidden by default, but there is a flag that enables turning them on. This way, we can use the "official" version without comments during our day-to-day work, but we can give the auditors two copies—both the "official" version and the "auditor" version that has all these extra notes.
Provide beautiful documents. A lot of times nobody readys requirements documents; we believe this is partly because the standard templates are large and ugly.
Make it as easy as possible to "upgrade" your documents when new versions of 62304 and related standards are developed.
The tool generates documents in markdown format, which are meant to be stored in source control, as well as in a PDF format. You can see examples of both the PDF and markdown versions here.
Please note that the tool is not complete, but it is under active development.
Not really related to regulatory compliance, but maybe Axiom can help. It can generate Word documents from your requirements.
There is a method called Model-Based Design by MathWorks which helps to integrate and automate most of the V&V processes required by the IEC 62304 for medical software development. In this way you can fulfil the steps all the way from requirements management to software integration and testing. The documentation artefacts required by the standard are automatically generated in the process.
For educational purposes, I am delving into some web development. What I have in mind right now is a website where users can submit as well as view benchmark scores for CPUs, GPus etc. As is evident, this will be heavily driven by a database which will store all the scores etc.
I have programming experience with OOPs (C++, C#), and am not too worried about picking up PHP. However, I feel intimidated by front-end design (HTML, CSS etc.), and for that reason am shying away from developing the website from scratch.
I'm using MS WebMatrix, but I'm not sure which CMS will be best suited for me. Currently, I've reviewed the following: DotNetNuke, Umbraco, Joomla, Drupal; but haven't been able to pinpoint one yet.
Any suggestions which will be best suited for my kind of website?
Most widespread like Wordpress and Drupal CMS (and others) are extensible, meaning that you can create your own content types following the imposed workflow of each one's architecture. So the best suited for you will be the one that take less time learning.
I will recommend you Wordpress because I found that the learning curve is minimal if you can read their PHP source code, that is no need to read a book in its nth edition to cover to cover.
This page is a good start point to create a post type for Bechmarks. But again you could accomplish the same with other CMS, say Drupal. A sibling site of SO is devoted solely to WordPress.
hope that helps!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My company is planning on developing a brand new web front-end application.
Some background:
It must "sizzle" i.e. a nice marketable look and feel.
Our development team has no Java experience, with limited experience in Silverlight, Javascript, JQuery or CSS.
Time to market is a factor.
We need to stream large amounts of data from an Oracle database.
It must support 500 - 1000 concurrent users
It will be hosted internally behind a firewall.
We need mapping (geo-spatial) capabilities.
Someone has recommended using GWT instead of Silverlight or Traditional technologies(Javascript, jquery, CSS etc.).
I am not sure if this is the right way to go? A lot of the GWT news is from 2007/2008. It makes me think that this technology is old and maybe dying.
If you had a choice would you choose GWT?
unfortunately two of your statements are mutually exclusive in this context:
Our development team has no Java experience
Time to market is a factor
I'm a Java programmer who has picked up GWT over the last year or so. It's immensely effective being able to write direct to the browser using a compiled language & mature development tools. I can fly through web-development faster than ever before (using ASP, JSP, ExtJS ...).
But, as the other commenters have said: if you've no Java experience you're going to find it a real challenge picking up both technologies (Java & GWT) in a short time. If you do manage to make it to market in a reasonable time I could only imagine the code base would be in very poor condition (since you'd be learning as you go) - which would be a very poor foundation for your organisation's shiny new venture.
There again, you don't have a 'lot' of skills in the other related skills you listed either.
I suspect there's a more effective solution. As some wise old goat project manager said:
I have three variables to delivering your project: time, cost and quality. Pick any two
In your situation, if the organisation wants a quality product in a short time, it's the cost factor that must compensate - your organisation should buy in some interim GWT expertise to give you a sound software architecture and to mentor your team for the next few months. After that you'll be ready to take the reigns, inheriting a quality codebase by 'standing on the shoulders of giants'.
As others have said, GWT definitely is not a dying project. Quite the contrary actually as there are now more than 20 regular contributors from within Google (versus a semi-dozen back in 2008). Wave (despite being discontinued as a Google service, it's still alive as an Apache Foundation project), Orkut, AdWords, Google Moderator and the new (still beta) Google Groups are made with GWT; and parts of Google Buzz and a few other projects at Google are built with it too.
Now as to your choice:
Silverlight is a dying technology. Microsoft made it clear that it now invests in "HTML5": http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
GWT is mostly a client-side toolkit, but it comes with "high productivity" tools for client-server communications (GWT-RPC and RequestFactory for end-to-end protocols, AutoBeans for easy JSON serialization). With UiBinder, you can easily put to use your web designer skills.
if you're comfortable with JS, then go for it, but then you'd have to choose the "right toolkit" (jQuery? Google Closure?). Otherwise (which seems to be the case), it really depends how much "ajaxy" you need/want to be. I'm a strong believer in "one-page apps", but YMMV, or you can have specific constraints that rule it out. In any case, you'd have to choose a server-side technology.
So, depending on your needs/wants and skills, I'd choose GWT or "some JS toolkit". In any case, you'll have full control over the look and feel (unless you choose one of the bloated players: ExtJS/ExtGWT, SmartGWT or similar; you'll probably have a shorter time-to-market with these, but you'll pay it later, in terms of performance, integration with other toolkits, and look-and-feel).
In the light of what you're saying about your skills, I would definitely recommend GWT (despite your lack of experience with Java); because lack of experience with JavaScript is far worse than lack of experience with Java (you're talking about a "large application", so it's really important to start building things right and/or have tools to help refactoring, which you'll have with Java).
#ianmayo replied while I was writing the above, and I can only second what he said!
GWT is definitely not old or dying! A lot of Google's own applications are developed using GWT. You can download the GBST case study and learn how the global financial company uses GWT to improve productivity and create a rich user experience. You have to know that when you use GWT you automatically use javascript, html, etc. You create a your gwt application in java, but when you compile it gwt creates a folder with html files, javascript code, css, etc...
I definitely recommend it!
In order not to mislead readers with above seemingly unanimous answers, keep objective view in respected stackoverflow, following review expressed exact experiences I had with using GWT. Whether GWT is dying depends on how many new apps will adopt it,Google trend can tell (gwt trend).
Excerpt from https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>
I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:
Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>
In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As #Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.
In conclusion...
GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on
First of all , GWT is not dying technology, its usage increases, and its latest version is 2.2. I am using GWT for 2 years, since version 1.6. Its improvements since them is quite amazing.
Since GWT is client side technology, it does have only positive effects of your application scaliblity feature. Because server side web technologies such as jsf, struts, wicket are server resource consumers, but gwt does not need any server resource to render user interface..
But there is problem for your team. Because your team has no java experience, it would be quite difficult to adapt yourself two new technologies java and gwt.. If you have time to learn , I would strongly suggest GWT.
It takes approx 1 year to become proficient in GWT. Using GWT pays off if you develop an application as sophisticated as MicrosoftOffice or PhotoShop. It makes no sense to use GWT for small and relatively simple apps, IMHO. GWT is a time killing framework indeed, and you have to have very strong reasons to use it. I think that 99% of web apps don't need GWT.
GWT is not dying framework, but time killing framework. It has security issue. You can do easily CSRF(Cross site request forgery) request to the GWT applications. Also Java and Javascript are totally different languages, you can't translate easily. For your productivity avoid GWT.
At the moment Iam evaluating java web frameworks. More precisely Iam talking about GWT, JSF2 and apache wicket. One very importent criteria in this evaluation is prototyping.
The prototyping process in my company can be described by the folloing:
The customer can produce GUIs with an easy to use WYSIWYG editor, by drag&drop-ing web components on the corporate predefined website structur. There is also a need for some litte dynamic being like navigation from one frame to another.
So Iam looking for tools. These tools should not only provide nice GUIs but also deliver
some basic code, which can be forwarded to the development. The aim is to avoid missunderstandings between designers and developers as much as possible. More or less the
developers just have to implements the code, but not to implement the optical requirements.
In addition it would be desirable to customize the components thats been used in the WYSIWYG editor. Does anyone know any good tools for the mentioned frameworks (GWT, JSF2, wicket)?
One of the challenges with WYSIWYG tools for UI is that you generally have to pick between rapid prototyping and maintainable code. Even then, as soon as you want to do something that's not supported by the prototyping tool, you can implement it as you would without the prototyping tool, but your round-trip functionality (namely turning your app back into something that can be edited) is broken or crippled unless extra work is done to generate the metadata that the editor needs.
Upgrading between major releases is another issue. Vendors and groups who have developed these tools have a historically spotty record of when they stop supporting older versions, reasonably because of limited resources and sometimes difficult problems with how to track solid innovation happening in the framework itself.
My suggestion instead is to prototype with an RIA prototyping tool like Balsamiq Mockups or use a grid system like 960 Grid to generate rapid prototypes, then use a web development framework that allows your developers to run the code with or without the backend server. Wicket has a tag called that is great for this kind of thing -- web devs can fill a div with stuff that a component should generate, and Wicket devs can wrap the contents of that tag with after they implement it. Both parties can coexist for a long time that way.
Try GWT Designer for GWT.
Introduction
Quick Start Guide
Download
There's nothing like this for Wicket that I know of. The closest you would get to any kind of resource reuse from your customer would be to give them a drag and drop HTML editor - the resulting HTML could then form the basis of Wicket page/panel layout.
if you are planing to use a javascript library, you may use extjs,
http://www.sencha.com/products/js/
they have developed a nice designer
www.sencha.com/products/designer/
there is also a port of ext in GWT
www.sencha.com/products/gwt/
You have to pay for a commercial license if your application isn't open source!
I am looking to develop a multi-user web application that supports the following key features:
fill out forms with demographic data on individuals
define and administer surveys & polls
generate nice reports with graphs)
user rights administration and generic login stuff
My dilemma is whether to use a CMS (Drupal?) or develop from scratch.
Putting the time and cost issues aside for a minute, which are an obvious CMS strength, what are the weaknesses and potential risks using a CMS? my gut tells me that a CMS will be very easy and quick to start with, but when the features list begins to grow - I will pay the bill with having to delve into unfamiliar DB structure and code, try to tweak existing modules or write my own from scratch.
Is it really better, over the long run, to use a CMS?
There are two basic types of CMSes:
focused on features
focused on flexibility
The first type - focused on features - usually offer lot of modules or extensions to expand the basic functionality. You can build your web site very quickly using ready-to-use third party modules. There's a disadvantage of this way - it isn't so easy to bend or customize these modules. Usually you need to rewrite them.
Drupal. WordPress and Joomla are good examples of the first type of CMSes.
The second type - focused on flexibility - somewhere called Content Management Frameworks - don't offer so much prefabricated modules, but offer much more tools and ways to make your structure and relationships between elements fit your needs. It takes more time to learn this kind of CMS or to build your fist web site, but you can easily customize anything you need.
Some examples of the second type CMSes: SilverStripe, Symphony CMS, appRain, MODx, ezPublish.
appRain is one of the best customizable option where you will get both option of CMS and also complex coding by it's framework.
Development process is also easy. New version 4.0.4 is on they way to be released.