#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2009
    Posts
    1
    Rep Power
    0

    Requirements and Estimates for Application Frameworks


    Hello! I work for a big software company, which I will not reveal to avoid image issues. A division of this company is now using RUP and UML since 2005 (four years). Now this division is on a task of building an application framework, so other applications can be developed upon it. This framework must provide well documented components and APIs, with stable features and requirements, so that it can evolve without breaking applications written for it. There will about 40 components, a window system and an integration infrastructure between applications (sort of a portal), all to the web platform. I know that this sounds insane or at least unnecessary, but that’s not the point. If you can’t accept that doing this is reasonable, please just pretend.

    The requirements for this framework are organized in about 60 use cases. Most of these use cases are not in format of a flow of operations between the actor and the system. Most of them are actually a list of phrase-like requirements, such as “When the user left-click on a button, it must change its graphics (for example, show as pressed), providing a visible feedback to the user”. Each major components or group of components has two use cases. For example, there are the use cases “Operate label”, “Operate grid”, “Define label”, “Define grid”. The “operate” use cases shows the user experience on these components. The “define” use cases shows the developer experience in building an application with such components.

    This project has 18 months of at least 10 simultaneous people, and we have one prototype that works on this platform. Now we must implement some important new features on this platform, and some people are complaining about the use cases documents. They tell the use cases are poorly written, out-of-date and few developers actually use and understand them. So there is a major effort to update the use cases, increasing detail level, dividing some in two or more, moving requirements from a use case to another, etc. We use UCP (use case points) for estimates, and this work, together with the implementation of new features, will take almost 9000 hours (according to UCP rules with 4 years of history).

    My question is: are use cases an efficient way to define requirements, get estimates and organize project tasks to develop a framework composed by APIs, components and protocols? If not, what should we use?

    Thanks in advance!
    DarthC
  2. #2
  3. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,540
    Rep Power
    1906
    Most of these use cases are not in format of a flow of operations between the actor and the system. Most of them are actually a list of phrase-like requirements, such as “When the user left-click on a button, it must change its graphics (for example, show as pressed), providing a visible feedback to the user”
    if i put it up like this:
    USER: click left mouse button
    SYSTEM: change its graphics (show as pressed)
    SYSTEM: provide visible feedback to the user

    Wil you not call that an interaction or flow of operations between the actor and system?

    are use cases an efficient way to define requirements
    "define requirements" could be a list and/or text.
    The Use Cases will be created based on the requirements

    but there is not a 100% answer on how a project should be managed
    Last edited by MrFujin; November 4th, 2009 at 07:35 AM.
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    May 2004
    Posts
    3,417
    Rep Power
    886
    There may be some correlation between use cases and component complexity, but it is not hard and fast. Development costs do track fairly well with design complexity however; but you can't always easily derive that complexity from use cases. Breaking your current set into more fine grained use cases will generally help in this regard, but how do you know when you have taken it far enough? The cost of honing them down sufficiently that your estimation models are accurate enough might exceed the sum of all your current estimation errors.

    I would run an analysis on your current data. What is the standard deviation of estimation errors? If you have a lot of cases where the estimate was way off, it might not matter that the average estimate was within bounds. It could be that you are discovering new domains of complexity in some areas of development. You might in fact, have grazed the low hanging fruit and find that further feature development requires higher multiples of complexity to continue (thus eviscerating your models). I would guess that your currently deployed practice is not a good fit for developing new frameworks. It might be adequate for organizations that always use one particular framework, but even then, you have to keep an eye on those statistics.
    I no longer wish to be associated with this site.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Feb 2004
    Location
    London, England
    Posts
    1,585
    Rep Power
    1373
    Is this for internal use only, or is it a product the company intends to sell? If it is for internal use only, then why are you building the framework in the first place? It sounds very much like any one of dozens of web frameworks that already exist, and you could save months of effort by using one of them instead.

    Anyway, there are two ways of developing frameworks. The first is the "Intelligent Design" approach that your company is using. Try to think of everything the framework needs to do up front (plus things it may or may not need to do, but better include them just in case...), and try and design the whole thing from scratch.

    The second is the "Evolution" approach. Instead of building the framework, go ahead and build the first application. When it is finished start on the second application, while keeping an eye out for functionality duplicated in the first app. When you find it, extract that functionality out, polish it up and make it reusable. Lather, rinse and repeat.

    I can virtually guarantee that using the first method you will end up with an unwieldy behemoth that is hard if not impossible to use. With the second method you will end up with a lean and flexible framework that may not do everything you need, but should be easy to add any missing functionality as needed.

    Also your use cases do not sound much like real use cases to me. I recommend reading "Writing Effective Use Cases" by Alistair Cockburn.

    Dave

    Comments on this post

    • darthc agrees

IMN logo majestic logo threadwatch logo seochat tools logo