Home > Archive > Software Engineering > December 2006 > Feasibility Study
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Peter 2006-11-29, 10:01 pm |
| Hello,
I need to do a feasibility study for a software project. However, I
can't seem to find any information on structures or templates. Does
anybody have any examples of one or software dev. methods that use this
technique?
Thanks in advance for any answer.
Best regards,
| |
| xpyttl 2006-11-29, 10:01 pm |
| Feasibility Study is old terminology for developing a business case. Back
when we used those words, we never got very good at it. Today, an
experienced analyst will make a high level estimate of the size of the
needed app, using high level requirements and a lot of experience. Based on
that size, and the history that you (hopefully) have of what it costs you to
build, buy, and/or deploy software, he will come up with a cost.
On the flip side, he will analyze the benefits.
Then it is a simple matter of (benefits-cost) / cost. If that number
exceeds whatever your investment criteria is, you go do the project.
An experienced estimator can actually do pretty well with costs. (Although
there are plenty of clueless estimators out there), The tough part is
making some sort of judgement about the wild claims the partner makes for
benefits. To make a good decision, you really need to make some sort of
judgement about what fraction of those bennies are actually achievable.
It can be hard for software guys to face when a project isn't a good thing
to do. Even if doing the project is worth a million bucks, if the company
can make two million bucks investing the money in something else, then it
isn't a good idea to do the project. And even good software estimates at
the feasibility study level aren't very good, so you want to have a killer
ROI before you support a project.
Then comes the really hard part when you tell the partner his project is a
turkey and you ain't gonna do it! In some particularly well run companies
the company makes this a little easier by having the sponsor sign on the
dotted line for the claimed savings. When the sponsor knows his next year
budget will be reduced by the claimed savings, he gets a lot more realistic
about the benefits.
...
"Peter" <poostwoud@gmail.com> wrote in message
news:1164836375.857310.261300@l12g2000cwl.googlegroups.com...
> Hello,
>
> I need to do a feasibility study for a software project. However, I
> can't seem to find any information on structures or templates. Does
> anybody have any examples of one or software dev. methods that use this
> technique?
>
> Thanks in advance for any answer.
>
> Best regards,
>
| |
| Phlip 2006-11-29, 10:01 pm |
| Peter wrote:
> I need to do a feasibility study for a software project. However, I
> can't seem to find any information on structures or templates. Does
> anybody have any examples of one or software dev. methods that use this
> technique?
Google for "spike solution".
The best feasibility study is to attempt to write a very few of the
project's features with highest business value. Attempt to finish within a
couple w s, and see if the result is useful in production.
If you succeed, the project is feasible, and if you fail, it is not.
If you succeed, then see if the project is sustainable, by attempting to
write the next batch of features, and put them online. Repeat, in order of
business priority, until the project has all the required features.
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| Vivekanandan M 2006-11-30, 4:09 am |
| Hello ,
> Peter wrote:
> Hello,
>
> I need to do a feasibility study for a software project. However, I
> can't seem to find any information on structures or templates. Does
> anybody have any examples of one or software dev. methods that use this
> technique?
Are you a project manager, who is not sure if the project is
technically feasible?
Best Regards,
Vivekanandan M
| |
|
| Hello,
Thanks everyone for the answers so far.
Well, actually this is the first time we're asked to do one and they
want a quotation for executing the study. But as I can't make a good
quotation when I don't know all ins and outs of such a study or
business case I'm trying to collect information on the subject.
So I thought the business case should contain the first steps when
analysing an application. My index for the document so far:
1. Introduction
2. Business Study, ins and outs on the customer.
3. Current software situation, what do the customers have already.
4. Software requirements, what do they want.
5. Functional model, how can it be done.
6. Problem Solution Proposals, improve current situation or start over?
Standard or custom software.
7. Time and costs, how much time do the proposals take and what are the
costs.
8. Conclusion, our advice.
Vivekanandan M schreef:
> Hello ,
>
>
> Are you a project manager, who is not sure if the project is
> technically feasible?
>
> Best Regards,
> Vivekanandan M
| |
| Vivekanandan M 2006-11-30, 7:59 am |
| Hello ,
> Peter wrote:
> Hello,
>
> Thanks everyone for the answers so far.
>
> Well, actually this is the first time we're asked to do one and they
> want a quotation for executing the study. But as I can't make a good
> quotation when I don't know all ins and outs of such a study or
> business case I'm trying to collect information on the subject.
> So I thought the business case should contain the first steps when
> analysing an application. My index for the document so far:
I guess you are trying to identify the technical complexity of the
work by doing the technical fesibility. Also if this is a fixed bid
project, you need to do the financial feasibility! At the end of the
day you need to show profits to your management for executing a
project!
IF you are sure that the customer will give this project to you,
first freez the scope of the project with your customer and both of you
should agree and sign the scope. Once the scope document is ready, do a
WBS. Only after doing the WBS you can do the cost estimation. On top of
the cost, you will add this cost that cost.... so that you can arrive
at your final price. You should also calculate your ROI!!
Best Regards,
Vivekanandan M
| |
|
| Hello,
Thanks for clearing up some choices. You are using some specific terms
like Scope Document and WBS (?). Are they part of a methodology? I'm
going to Google for them as well.
Regards,
Peter
Vivekanandan M schreef:
> Hello ,
>
>
> I guess you are trying to identify the technical complexity of the
> work by doing the technical fesibility. Also if this is a fixed bid
> project, you need to do the financial feasibility! At the end of the
> day you need to show profits to your management for executing a
> project!
>
> IF you are sure that the customer will give this project to you,
> first freez the scope of the project with your customer and both of you
> should agree and sign the scope. Once the scope document is ready, do a
> WBS. Only after doing the WBS you can do the cost estimation. On top of
> the cost, you will add this cost that cost.... so that you can arrive
> at your final price. You should also calculate your ROI!!
>
> Best Regards,
> Vivekanandan M
| |
| Vivekanandan M 2006-11-30, 7:59 am |
| Hello ,
> Peter wrote:
> Hello,
>
> Thanks for clearing up some choices. You are using some specific terms
> like Scope Document and WBS (?). Are they part of a methodology? I'm
> going to Google for them as well.
Please gothrough PMBOK from PMI. WBS is Work Breakdown Structure.
Best Regards,
Vivekanandan M
| |
| H. S. Lahman 2006-11-30, 7:01 pm |
| Responding to Peter...
> I need to do a feasibility study for a software project. However, I
> can't seem to find any information on structures or templates. Does
> anybody have any examples of one or software dev. methods that use this
> technique?
The first thing you have to do is determine what 'feasible' means for
your project.
Is there a specific concern? For example, the application has to solve
an np-Complete problem and you aren't sure whether you will need a
bigger computer than the one proposed. Or the application has hard
real-time constraints that you aren't sure can be satisfied.
Is feasibility defined purely in cost (i.e., expended effort)? That is,
if too many resources will be needed to complete it in a given time, is
it infeasible?
Is feasibility defined in terms of design strategies already defined?
For example, you would like to use an OODB but you aren't sure if that
will work better for the problem in hand than an RDB.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| Hello,
Thanks for your response! You are quite right about the fact I'm not be
really clear on what 'feasible' means in my case. I will try to create
a more complete pricture on my problem.
The company I work for wants to setup a new service that will rely
heavily on automating the processes concerned with the service.
Their current situation is already partially capable of supporting the
service, however they want to know what is needed to be able to support
the service fully (Just the basic functionality, no fancy stuff) and of
course the time and costs that is needed.
So, with my basic knowledge I came up with the following structure:
1. Introduction
2. Company Study, information on the company, vision, structure, goals,
acitivities, etc.
3. System Requirements Specification, what kind of functionality the
new system must support (MoSCoW)
4. Current Situation, how do they currently work
5. System Proposal, recommendation based on the results of several
alternatives
6. Resource Requirements, what is needed and what will it cost to
execute the system proposal.
However I feel like I'm missing information here, so I was hoping for a
guideline of some sort that will help as a reminder.
I hope this makes the situation more clear and that you can provide me
with more information.
Again thanks in advance for your answers!
Best regards,
Peter
H. S. Lahman schreef:
> Responding to Peter...
>
>
> The first thing you have to do is determine what 'feasible' means for
> your project.
>
> Is there a specific concern? For example, the application has to solve
> an np-Complete problem and you aren't sure whether you will need a
> bigger computer than the one proposed. Or the application has hard
> real-time constraints that you aren't sure can be satisfied.
>
> Is feasibility defined purely in cost (i.e., expended effort)? That is,
> if too many resources will be needed to complete it in a given time, is
> it infeasible?
>
> Is feasibility defined in terms of design strategies already defined?
> For example, you would like to use an OODB but you aren't sure if that
> will work better for the problem in hand than an RDB.
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> info@pathfindermda.com for your copy.
> Pathfinder is hiring:
> http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH
| |
| Vivekanandan M 2006-12-01, 4:01 am |
| Hello ,
> Peter wrote:
> Hello,
>
> Thanks for your response! You are quite right about the fact I'm not be
> really clear on what 'feasible' means in my case. I will try to create
> a more complete pricture on my problem.
> The company I work for wants to setup a new service that will rely
> heavily on automating the processes concerned with the service.
> Their current situation is already partially capable of supporting the
> service, however they want to know what is needed to be able to support
> the service fully (Just the basic functionality, no fancy stuff) and of
> course the time and costs that is needed.
> So, with my basic knowledge I came up with the following structure:
>
> 1. Introduction
> 2. Company Study, information on the company, vision, structure, goals,
> acitivities, etc.
> 3. System Requirements Specification, what kind of functionality the
> new system must support (MoSCoW)
> 4. Current Situation, how do they currently work
> 5. System Proposal, recommendation based on the results of several
> alternatives
> 6. Resource Requirements, what is needed and what will it cost to
> execute the system proposal.
>
> However I feel like I'm missing information here, so I was hoping for a
> guideline of some sort that will help as a reminder.
>
> I hope this makes the situation more clear and that you can provide me
> with more information.
I suggest you gothrough PMBOK from PMI.
Best Regards,
Vivekanandan M
| |
|
| Peter wrote:
> 1. Introduction
> 2. Company Study, information on the company, vision, structure, goals,
> acitivities, etc.
Make a list of everyone available to help on the project, and everyone
available to provide input. This is the "project community", and the list
should include everyone out to the receptionist.
Identify which characters within that list will decide which features the
system should have.
That effort will typically generate the "information on the company,
vision", etc.
> 3. System Requirements Specification, what kind of functionality the
> new system must support (MoSCoW)
Specify the high-priority items in detail, and leave the low-priority items
as general "goals". Get buy-in from the project community on all the details
and all the goals. Use this opportunity to _censor_ any item that nobody
actually wants.
Many a project has gone into trouble after a diligent "requirements
gathering" phase that gathered hundreds or thousands of requirements, then
neglected to censor out the unimportant ones. Programmers work very hard,
for a long time, then deliver features that cannot be used in their current
form. Then they rework!
> 4. Current Situation, how do they currently work
The big decision here is whether to re-write or tweak an existing system.
Some project try a little of both and do very well.
> 5. System Proposal, recommendation based on the results of several
> alternatives
Including attempts at live source code, to see if these alternatives are
realistic, and to collect hard data on their feasibility.
> 6. Resource Requirements, what is needed and what will it cost to
> execute the system proposal.
This is "budget". Do not use the requirements to detect that your project
_must_ have a MegaDataServer from some high-end data warehouse vendor. Start
small and scale; don't start big, because getting rid of stuff you don't
need is much harder than learning what few things you do need. If you
eventually need a real data warehouse, your live code will tell you exactly
what its specifications are. You can then make decisions with lots of hard
data to back them up; not lots of guesswork.
> However I feel like I'm missing information here, so I was hoping for a
> guideline of some sort that will help as a reminder.
Google "Lean Software Development".
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| carhar 2006-12-01, 7:01 pm |
| IMHO the feasibility study itself is a project with a plan and
objectives and deliverables and costs. It may or may not justify and
spawn the desired project if found feasible.
Peter wrote:
> Hello,
>
> I need to do a feasibility study for a software project. However, I
> can't seem to find any information on structures or templates. Does
> anybody have any examples of one or software dev. methods that use this
> technique?
>
> Thanks in advance for any answer.
>
> Best regards,
| |
|
| carhar wrote:
> IMHO the feasibility study itself is a project with a plan and
> objectives and deliverables and costs. It may or may not justify and
> spawn the desired project if found feasible.
That's I said at first: Run the first few features of the project itself.
I was resoundingly ignored. Some shops value paperwork over working code...
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| H. S. Lahman 2006-12-01, 7:01 pm |
| Responding to Peter...
> Thanks for your response! You are quite right about the fact I'm not be
> really clear on what 'feasible' means in my case. I will try to create
> a more complete pricture on my problem.
> The company I work for wants to setup a new service that will rely
> heavily on automating the processes concerned with the service.
> Their current situation is already partially capable of supporting the
> service, however they want to know what is needed to be able to support
> the service fully (Just the basic functionality, no fancy stuff) and of
> course the time and costs that is needed.
This sounds more like they are looking at things from a resource
perspective -- the number of people, hardware, and software development
effort that will be needed for full support.
> So, with my basic knowledge I came up with the following structure:
>
> 1. Introduction
> 2. Company Study, information on the company, vision, structure, goals,
> acitivities, etc.
This is boilerplate and I wouldn't spend much effort on it. The company
should pretty much know where they are right now. The main reason for
(2) is to make sure you are on the same page as whoever is doing the
company's strategic thinking. Still, I would keep this to a page of less.
> 3. System Requirements Specification, what kind of functionality the
> new system must support (MoSCoW)
> 4. Current Situation, how do they currently work
I would be inclined to reverse these two. The feasibility is around the
delta of requirements from what they provide now and what they hope to
provide. So I would regard (4) as more pro forma boilerplate to
establish context.
However, I would spend some serious time on (3) because that defines the
basis of the feasibility estimates. You don't want the detail of formal
requirements, but you do need to highlight the most significant general
requirements that need to be addressed for full service support.
> 5. System Proposal, recommendation based on the results of several
> alternatives
Do you mean different levels of "full" or different approaches to
delivering the same notion of "full support"?
My pushback is whether there really are a lot of alternatives. It seems
to me that it is likely that the alternatives are really based upon the
set of new requirements. That is, alternatives would represent
different sets of requirements to be implemented, in which case you
would have to make those sets clear in (3).
My point is that there may be a passle of design decisions that will
have to be made, but those aren't alternatives to the level of support;
they are just design decisions. For feasibility purposes the level of
abstraction of requirements is so high that the software is a black box.
For example, let's assume the problem is to provide better Customer
Support and all the company does now is provide rudimentary phone
support. Modern Customer Support implies one needs chat, eMail, and a
knowledge base as well. Those things are pretty much fixed. While the
software supporting them may vary in sophistication, your estimates are
going to have to be based on a black box guess at what is involved in,
say, providing chat support. IOW, there really aren't any alternatives.
(OTOH, providing software tools for remote access of the user's
machine for diagnostics, etc. is more likely to be an alternative level
of support whose resources need to be estimated separately.)
At the other extreme, suppose the problem is to provide support to
online traders in stocks and commodities. Then one is talking about
adding a bunch of essentially standalone tools for sophisticated
analysis (e.g., What If simulations), perhaps with some "backplane" for
pipelining results from one analysis tool to another. This is very
open-ended from a requirements perspective. About all you can do here
is guess at what the average effort is to develop an individual tool and
then provide a graph of estimated effort for various numbers of tools.
There are variations, such as categorizing tool complexity by low,
medium, high. [Note that this changes the context of feasibility
because the open-ended nature means that the list of tools will
inevitably grow over time so there is not solid "full support" target
and one /must/ think of things incrementally.]
> 6. Resource Requirements, what is needed and what will it cost to
> execute the system proposal.
This and (3) is where the real meat of the feasibility analysis.
Assuming feasibility is in terms of effort and hardware cost, then the
real job of the analysis is providing estimates.
If the broad brush requirements can be isolated (e.g., supporting chat
Customer help), then you can provide estimates for the software support
for each requirement. So when you do (3) keep the link with (6) in mind
when you select the level of abstraction for the requirements.
> However I feel like I'm missing information here, so I was hoping for a
> guideline of some sort that will help as a reminder.
If my assumption is correct about what 'feasibility' means in your
context, I don't think so. In fact, I would argue for keeping
everything except (3) and (6) as short as possible. Also remember that
managers have short attention spans. At some point you need an
Executive Summary view like a table with requirements and effort
estimates. Organizing (3) and (6) so they play together smoothly will
probably yield such a view.
One last piece of advice is to think about (3) and go back to whoever
commissioned this study and do a sanity check with them. You need to
know whether the list of new requirements is (a) at the right level of
abstraction and (b) the right set of requirements before you go to the
trouble of estimating.
--
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| Hello Phlip and Lahman,
I'm still really insecure on the subject and again I would like to
thank you for your answers so far. They are really helpful for me to
form an image on how to do the study!!
I'm very interested in using a lean method as the involvement of the
customer has an important role, which I think is one of the most
important things when developing a system. Are your answers based on
the thought of using Lean System Development as well Lahman?
When searching for "lean methods" on the internet I found dsdm
(www.dsdm.org) which caught my interest. I think you both know the
system. It's life cycle is based on the following steps:
1. Feasibility, can dsdm be used for the project
2. Business Study, which processes and usergroups need to be supported
by the system, defining the project community, etc.
3. Functional Model Iteration, defining what is needed to automate in
cooperation with the project community.
4. Design and Build iteration, how can the functional model be build
5. Implemenation, round-up, training and evaluation.
As I understand lean so far this lifecycle is pretty common. So when
translating this to the feasilbity study as I need it, this lead to the
following structure:
1. Introduction
2. Business Study, same as dsdm
3. Functional Model Iteration, same as dsdm (should I include
prototyping??). However as you describe I only should focus on the most
important items, so doesn't take iteration to much time? Is there
anyway to determine you have all the high priority items?
4. Current Situation, I believe this is still important as it might be
cost-saving to reuse, remake or tweak some parts of the current system.
5. Technical Design, dsdm uses a design and build iteration. However I
need to make an estimation on the resources so I believe the build part
should be left out for the study as otherwise I would already be
building the system. This chapter only describes the techniques used
for building the system. Also described is which parts of the current
situation can be used, if there is a possibility for using standard
software instead writing custom.
6. Resource Requirements, based on the information in the other
chapters I will try to make an estimation on the resources and
iterations needed to build and implement the system.
It looks the old structure, however for now I more or less chose the
lean approach.
I find this all very complex, as I'm wondering with my little
experience if I'm able to make an acceptible estimation for the system.
I hope don't bore you with my rookie approach, but I want to get a grip
on this, so I'll be keeping asking questions till then :) (of course
hoping for answers as you guys did so far!)
H. S. Lahman schreef:
> Responding to Peter...
>
>
>
> This sounds more like they are looking at things from a resource
> perspective -- the number of people, hardware, and software development
> effort that will be needed for full support.
>
>
> This is boilerplate and I wouldn't spend much effort on it. The company
> should pretty much know where they are right now. The main reason for
> (2) is to make sure you are on the same page as whoever is doing the
> company's strategic thinking. Still, I would keep this to a page of less.
>
>
> I would be inclined to reverse these two. The feasibility is around the
> delta of requirements from what they provide now and what they hope to
> provide. So I would regard (4) as more pro forma boilerplate to
> establish context.
>
> However, I would spend some serious time on (3) because that defines the
> basis of the feasibility estimates. You don't want the detail of formal
> requirements, but you do need to highlight the most significant general
> requirements that need to be addressed for full service support.
>
>
> Do you mean different levels of "full" or different approaches to
> delivering the same notion of "full support"?
>
> My pushback is whether there really are a lot of alternatives. It seems
> to me that it is likely that the alternatives are really based upon the
> set of new requirements. That is, alternatives would represent
> different sets of requirements to be implemented, in which case you
> would have to make those sets clear in (3).
>
> My point is that there may be a passle of design decisions that will
> have to be made, but those aren't alternatives to the level of support;
> they are just design decisions. For feasibility purposes the level of
> abstraction of requirements is so high that the software is a black box.
>
> For example, let's assume the problem is to provide better Customer
> Support and all the company does now is provide rudimentary phone
> support. Modern Customer Support implies one needs chat, eMail, and a
> knowledge base as well. Those things are pretty much fixed. While the
> software supporting them may vary in sophistication, your estimates are
> going to have to be based on a black box guess at what is involved in,
> say, providing chat support. IOW, there really aren't any alternatives.
> (OTOH, providing software tools for remote access of the user's
> machine for diagnostics, etc. is more likely to be an alternative level
> of support whose resources need to be estimated separately.)
>
> At the other extreme, suppose the problem is to provide support to
> online traders in stocks and commodities. Then one is talking about
> adding a bunch of essentially standalone tools for sophisticated
> analysis (e.g., What If simulations), perhaps with some "backplane" for
> pipelining results from one analysis tool to another. This is very
> open-ended from a requirements perspective. About all you can do here
> is guess at what the average effort is to develop an individual tool and
> then provide a graph of estimated effort for various numbers of tools.
> There are variations, such as categorizing tool complexity by low,
> medium, high. [Note that this changes the context of feasibility
> because the open-ended nature means that the list of tools will
> inevitably grow over time so there is not solid "full support" target
> and one /must/ think of things incrementally.]
>
>
> This and (3) is where the real meat of the feasibility analysis.
> Assuming feasibility is in terms of effort and hardware cost, then the
> real job of the analysis is providing estimates.
>
> If the broad brush requirements can be isolated (e.g., supporting chat
> Customer help), then you can provide estimates for the software support
> for each requirement. So when you do (3) keep the link with (6) in mind
> when you select the level of abstraction for the requirements.
>
>
> If my assumption is correct about what 'feasibility' means in your
> context, I don't think so. In fact, I would argue for keeping
> everything except (3) and (6) as short as possible. Also remember that
> managers have short attention spans. At some point you need an
> Executive Summary view like a table with requirements and effort
> estimates. Organizing (3) and (6) so they play together smoothly will
> probably yield such a view.
>
> One last piece of advice is to think about (3) and go back to whoever
> commissioned this study and do a sanity check with them. You need to
> know whether the list of new requirements is (a) at the right level of
> abstraction and (b) the right set of requirements before you go to the
> trouble of estimating.
>
> --
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> info@pathfindermda.com for your copy.
> Pathfinder is hiring:
> http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH
| |
| H. S. Lahman 2006-12-04, 4:01 am |
| Responding to Peter...
> Hello Phlip and Lahman,
>
> I'm still really insecure on the subject and again I would like to
> thank you for your answers so far. They are really helpful for me to
> form an image on how to do the study!!
>
> I'm very interested in using a lean method as the involvement of the
> customer has an important role, which I think is one of the most
> important things when developing a system. Are your answers based on
> the thought of using Lean System Development as well Lahman?
No. A feasibility study really doesn't depend on any particular
software development process. In fact, it really belongs in the realm
of product development.
> When searching for "lean methods" on the internet I found dsdm
> (www.dsdm.org) which caught my interest. I think you both know the
> system. It's life cycle is based on the following steps:
I never heard of this one, but a lot of processes for rapid product
development sprang up in the '90s. However, in a product development
context 'feasibility' is usually more related to market analysis than
software cost estimation.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| H. S. Lahman wrote:
> No. A feasibility study really doesn't depend on any particular
> software development process. In fact, it really belongs in the realm
> of product development.
If you include in the study the question which methodology to use, and
if one of them reduces risk by producing live code, then...
> I never heard of this one, but a lot of processes for rapid product
> development sprang up in the '90s.
Lean ain't RAD. RAD means reducing quality under the illusion of
short-term gains. Lean means keeping quality high to obtain both
short-term and long-term benefits.
> However, in a product development
> context 'feasibility' is usually more related to market analysis than
> software cost estimation.
Then why is a software engineer doing it?
--
Phlip
| |
| H. S. Lahman 2006-12-05, 7:00 pm |
| Responding to Phlip...
>
>
> If you include in the study the question which methodology to use, and
> if one of them reduces risk by producing live code, then...
OK, I should have put in a qualifier like 'usually'.
IME, though, while developers sometimes need to do feasibility studies
to select design strategies, that is usually lumped under prototyping or
project planning. In the OP's case the study seems to be primarily
about product cost, in which the case the developers just provide
estimates as input and the study would normally be owned by the Product
Manager -- in a company that actually did RAD product development.
>
>
> Lean ain't RAD. RAD means reducing quality under the illusion of
> short-term gains. Lean means keeping quality high to obtain both
> short-term and long-term benefits.
First, I am talking about RAD _product development_, which the reference
seemed to be focused on rather than software development.
Second, there is nothing in RAD, either at the product or software
levels, that implies sacrificing quality.
>
>
> Then why is a software engineer doing it?
Probably for the same reason that SEs often end up formalizing
requirements: the Marketeers didn't want to take the time to write it up.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
|
|
|
|
|