On Mon, Feb 23, 2009 at 11:44 AM, James Byrne <li...@ruby-forum.com> wrote: > > F=31, S=165, PC=100%, TU=30, CU=21, financial services (insurance > claims)
Whathuh? Wow, you really *do* work for government, don't you? >8-> That line hurts me to look at and I'm not going to try to put my answer in that format. Since I've started using Cucumber I've mostly been doing smaller projects, and the only ones I've completed or brought near completion have been personal ones. My last project was a spike that had to be done inside a week and I abandoned most testing (and it shows), but apart from that it seems like the projects I consider 'smallish' tend to have about 10-30 features, with usually 5-10 scenarios per feature. If I had to think about how feature counts scale, I'd say that in the most general case they scale by significant models. A "significant model" is an entity that really matters to the business process (as in, you can't describe the process without it) and that has a non-trivial interface. If I'm building a membership registration system, "Member" is certainly a significant model. "Payment" is significant. "Phone number" probably isn't, even if I break it out into a separate table and Rails model for relational reasons. A significant model will likely have somewhere from 2-5 features simply by virtue of CRUD operations. You need to be able to view the information. That's a feature. You need to be able to edit it. That's a feature too. Whether create/update/delete are separate features or all one feature varies by how complex or different the interface needs to be in each case. If it's all one form and that form has a "Delete" button with a simple yes/no confirmation, you can probably cover it with one feature. Sometimes you can't. ...And sometimes there's a need for imports or printed reports or whatever, and those are all features. So that's how I gauge this stuff. The driving metric is interface complexity and the number of different major interactions an actor could have with the application. I don't know how to gauge "percent completion" off of that, or why the nature of the industry would be important. And... "Total or concurrent users?" That you're asking for that information totally baffles me. How could that possibly make a difference to the number of features? That's a scaling issue. An implementation detail, unrelated to app complexity or business value. If I wrote an executive information system that only had 15 users, but those users used it to save millions of dollars, how does the number "15" help you determine how many features you should write? -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
