locked
Software development process control RRS feed

  • Question

  • I am afraid my question will be a bit off-topic and maybe stupid question to ask. However, I would really like to get some inputs from some architects or project managers.

    I am trying to develop a standard to control our development process so that the work should be sustainable. I am working out the project requirement gathering phase. In this phase, I think the process will be something like below.


    Project Initiator (PI): Create new business requirement
    Business Analyst (BA): Analyse the business requirement provided by PI
    BA: Decide whether new development is needed or suitable
    Project Manager (PM): Receive the preliminary request from BA and estimate the resource needed roughly

    Project Manager (PM): Determine whether it is possible to accept the new task based on current available resource

    System Analyst (SA): If resource is available, SA starts interview the PI to gather detail project requirement.

    SA: Estimate the resource needed after the user requirement is obtained.

    SA: Create a detail functional specification

    BA: Review the specification and approve/reject the spec. If rejected, SA needs to modify the spec.

    SA: Present the functional spec. to user

    PI: Review and endorse the functional spec.


    As you can see, the picture is quite raw but I think we do the same in real life. What I am trying to work out is a standard of such software development so that other parties can monitor/control the process.


    I think this kind of process must exist in large corporation. I think it'll involve much more parties and departments. Is there any sample that I can find somewhere?

    Wednesday, May 21, 2008 1:40 PM

Answers

  •  

    MSF would be a good resource to look at - that has this sort of information as part of its methodology.  It would be a starting point at least.

     

    I'd say that the project initiator would define things like project vision, some scoping and generally starting the project off.  I'd expect then that the BA would be talking to the domain experts to gather requirements.

     

    The SA or architect should then be driving the BA to understand the business requirements, and possibly suggest clarification of those business requirements, or suggesting risks around particular features.  I think that the user and domain expect should be involved at this stage to ensure that the process is taking place according to usage scenarios.

     

    Is a functional specification going to be relevant to a user?  If the user is the domain expert it might be, in which case you need clarity on the roles that you have assigned.

     

    Estimates can be given based on the business requirements, then as the SA refines on the requirements again, and analysis and design can take place, and developers can also give estimates that are likely to be much more closely based on what is actually achievable.

     

    I think that your process appears to be more traditional and driven from a PM perspective.  I think that whether you like it or not, any software PM methodology is inherently agile to some extent.  If the project runs from beginning to end, is delivered, and needs enhancements, then a new set of services packs, or enhancements are made, that's another iteration.  My view is that we should always look at a software project in that way.

     

    Good luck,

     

    Martin Platt.

     

     

    Thursday, May 22, 2008 2:40 AM
  • Hi Alex,

         Did you had a chance to look at Agile methodologies?

    http://www.controlchaos.com/about/ has a decent description of Scrum...

     

    VersionOne has a free tool that you can download for managing scrum projects and ThoughtWorks' mingle has a awesome tool that I use for agile projects.  Both are free for limited user and there is a cost for enterprise licensing.  XPlanner is an opensource tool for the same.

     

    Hope this helps.

     

    Thanks,

    Gaja

     

    Thursday, May 22, 2008 3:16 PM
  • I'll add a couple of resources from Roger Pressman's site, on Software Engineering and the SDLC.

     

    I'd also strongly suggest his book (now two books), which to me should be on the bookshelf of any software professional and even software manager.

     

    Software Engineering Resources

    http://www.rspa.com/spi/index.html

     

    Adaptable Process Model

    http://www.rspa.com/apm/index.html

     

    Hope it helps.

     

    -LV

    Friday, May 23, 2008 4:35 AM




  • If you are going to be using TFS, and want to know more about Scrum, take a look at:

    www.scrum-master.com

    If you're after something specifically for Scrum take a look at:

    www.agilealliance.com/show/1369
    www.scrumalliance.org
    www.controlchaos.com/about/

    And if you're interested in agile methodologies, look at:

    www.agilealliance.org
    www.agileadvice.com

    If you're interested in a book, there's one here:

    www.microsoft.com/mspress/books/6916.aspx

    If you're still stuck, you should google some other agile or scrum books, and sites, such as Thoughtworks.

    I hope that helps,

    Martin Platt.

    Wednesday, June 4, 2008 12:34 AM

All replies

  •  

    MSF would be a good resource to look at - that has this sort of information as part of its methodology.  It would be a starting point at least.

     

    I'd say that the project initiator would define things like project vision, some scoping and generally starting the project off.  I'd expect then that the BA would be talking to the domain experts to gather requirements.

     

    The SA or architect should then be driving the BA to understand the business requirements, and possibly suggest clarification of those business requirements, or suggesting risks around particular features.  I think that the user and domain expect should be involved at this stage to ensure that the process is taking place according to usage scenarios.

     

    Is a functional specification going to be relevant to a user?  If the user is the domain expert it might be, in which case you need clarity on the roles that you have assigned.

     

    Estimates can be given based on the business requirements, then as the SA refines on the requirements again, and analysis and design can take place, and developers can also give estimates that are likely to be much more closely based on what is actually achievable.

     

    I think that your process appears to be more traditional and driven from a PM perspective.  I think that whether you like it or not, any software PM methodology is inherently agile to some extent.  If the project runs from beginning to end, is delivered, and needs enhancements, then a new set of services packs, or enhancements are made, that's another iteration.  My view is that we should always look at a software project in that way.

     

    Good luck,

     

    Martin Platt.

     

     

    Thursday, May 22, 2008 2:40 AM
  • Dear Martin,

    I am interested in what is the modern approach if my approach is relatively traditional? Can you give me some directions please? Thanks!

    Regards,
    Alex
    Thursday, May 22, 2008 3:17 AM
  • Hi Alex,

         Did you had a chance to look at Agile methodologies?

    http://www.controlchaos.com/about/ has a decent description of Scrum...

     

    VersionOne has a free tool that you can download for managing scrum projects and ThoughtWorks' mingle has a awesome tool that I use for agile projects.  Both are free for limited user and there is a cost for enterprise licensing.  XPlanner is an opensource tool for the same.

     

    Hope this helps.

     

    Thanks,

    Gaja

     

    Thursday, May 22, 2008 3:16 PM
  • I'll add a couple of resources from Roger Pressman's site, on Software Engineering and the SDLC.

     

    I'd also strongly suggest his book (now two books), which to me should be on the bookshelf of any software professional and even software manager.

     

    Software Engineering Resources

    http://www.rspa.com/spi/index.html

     

    Adaptable Process Model

    http://www.rspa.com/apm/index.html

     

    Hope it helps.

     

    -LV

    Friday, May 23, 2008 4:35 AM




  • If you are going to be using TFS, and want to know more about Scrum, take a look at:

    www.scrum-master.com

    If you're after something specifically for Scrum take a look at:

    www.agilealliance.com/show/1369
    www.scrumalliance.org
    www.controlchaos.com/about/

    And if you're interested in agile methodologies, look at:

    www.agilealliance.org
    www.agileadvice.com

    If you're interested in a book, there's one here:

    www.microsoft.com/mspress/books/6916.aspx

    If you're still stuck, you should google some other agile or scrum books, and sites, such as Thoughtworks.

    I hope that helps,

    Martin Platt.

    Wednesday, June 4, 2008 12:34 AM
  • As my colleagues say, there exists a bundle of approaches so you don't need to start from scratch

     

    Approaches are better or worse depending on context

     

    Certain companies preferred a fully formalized, measurable, repeatable process privileging its control

     

    Certain others prefer an emphasis on delivery, still trying to keep control but avoiding the process to become an obstacle

     

    All these debate enters under the frame of "Change Management" and there's plenty of templates (including stakeholders, etc) in bibliography. Folks here have suggested several of those

    Wednesday, June 18, 2008 1:16 AM
  •  Diego Dagum wrote:

    As my colleagues say, there exists a bundle of approaches so you don't need to start from scratch

     

    Approaches are better or worse depending on context

     

    Certain companies preferred a fully formalized, measurable, repeatable process privileging its control

     

    Certain others prefer an emphasis on delivery, still trying to keep control but avoiding the process to become an obstacle

     

    All these debate enters under the frame of "Change Management" and there's plenty of templates (including stakeholders, etc) in bibliography. Folks here have suggested several of those

     

    I don't think so, and it is not by chance that I suggested resources on Software Engineering.

     

    Before reengineering you have to engineer, before changing you have to be.

     

    Also your "there are certain who do this and certain who do that" is again the most common way to devoid any serious discussion of any chance to happen around here.

     

    Let's have a beer then, what is software architecture after all?

     

    -LV

    Wednesday, June 18, 2008 10:21 PM
  •  Diego Dagum wrote:

    As my colleagues say, there exists a bundle of approaches so you don't need to start from scratch

     

    Approaches are better or worse depending on context

     

    Certain companies preferred a fully formalized, measurable, repeatable process privileging its control

     

    Certain others prefer an emphasis on delivery, still trying to keep control but avoiding the process to become an obstacle

     

    All these debate enters under the frame of "Change Management" and there's plenty of templates (including stakeholders, etc) in bibliography. Folks here have suggested several of those

     

    That's right, in the real world different companies have different emphasis. E.g You'll see a number of people that suggest SCRUM is only useful for small developments whereas others will disagree. Equally if your project is to change the style of a few web pages would PRINCE be a good choice? IMO it also depends on the people you get to work with. It's not always possible to simply employ the "best team" and you have to work with what you've got. If you're working with people that like to be told exactly what to do without applying thought or asking questions (and I won't get into cultural realities here) then you'll need rigid structures. On the other hand you may have a very engaged team that dislike rigid structure where the company manages some of the risk by relying on the individuals skills. So I agree with Diego that practically you'll need to choose the write tool/methodology/practices for your needs.

    Although there's probably a months worth of reading here already, I'd strongly recommend looking over http://www.agilejournal.com/ as it has some nice well balanced articles about exactly these sorts of issues.

     

     

     

    Friday, June 20, 2008 7:10 AM
  • I would ask the development compliance vendors that already have templates for development processes and ITIL processes. They usually require bpm software to run these processes, but their documentation should be a good starting point.

     

     

    Ruth Stark - BPM Analyst

    Wednesday, November 19, 2008 6:13 PM