locked
How to design an project RRS feed

  • Question

  • Hi,

    I have been teaching myself programming for about 18 months, playing with Java, C# and PHP. Now as i want to start taking a more proffesional approach i am curious on how other people manage projects.

    for instance, if you are required to make a CRM application. Where do you start. what applications help you? up until now when i work on my little "projects" its all in my head. what i want it to do, look like, how i want it people to interact with it. 

    I have looked at UML. is that what people use? 

    Please share your thoughts and ideas.. 
    Thursday, April 2, 2009 8:22 AM

Answers

  • The question for me deals with company politics, product features, timelines, frameworks, methodologies.

    Company politics:  How much documentation is required to tell everyone about the new project vs how much documentation is actually needed to get the job done.

    Product features:  Is the project/product super simple in that all features can be written on a sticky note or white board or are there so many complex inter-related features that you really need to create a proof of concept, various UML diagrams, software requirements specification (search google for this term and the .doc extension for the template).

    Timeline:  Do you have a year and a half to build the project where 6 months can be dedicated to documentation or do you have a month in which case I like to use SmartSheet.com to jott down my soft requirements for a quick sign off.

    Frameworks:  Can you use a pre-existing framework such as Microsofts Enterprise Application blocks, StructureMaps DI tool, LINQ to SQL or NHibernate data access, Dynamic Data Web Sites, .NET profiles, etc.  If so, some of the complexity is removed from your design and therefore so is the need to specify it.  Think black box.

    Methodologies:  Are you working in a fast paced "Agile" world where documentation is a bad word and forward motion is the keyword of the day or do you work in a lame old school way of thinking waterfall style world (guess which one I prefer?).  Agile tends to brag about less documentation but some is still a good idea!  If for nothing other than covering your butt when things don't quite work as well as others thought they should/would.  Waterfall generally requires you to describe every nut in the system (...to include the nuts thread type, whether it is coarse or fine, the type of metal used to create the nut, the weight of the nut, the shape of the nut, the direction to turn it when putting it on, which tool is used to put it on, which tool is used to take it off, how many turns to issue for proper usage, etc.....<agile just says get the nut that fits the bolt and tighten it>).  This comes down to are you building a financial application or an image gallery?  More complexity tends to work best with an appropriate amount of planning and documentation.

    Where do I start?  SmartSheet (or similar) and a white board session with everyone involved in the project.

    Oh and....C#!
    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    • Marked as answer by TyronGower Friday, April 3, 2009 10:05 PM
    Thursday, April 2, 2009 8:50 AM
  • UML is a popular way of communicating software models, so this is almost prerequisiste knowledge working in teams on large projects (assuming you're working in an object oriented language).

    When communicating a design you will probably want to use a mixture of UML and plain text to supplement the diagrams.  In the early stages of a project I use informal UML diagrams on a white board.  Often, I capture these using a digital camera and combine them in a document that is easily accessible to all stakeholders.  It's also easier to take to a meeting than a whiteboard :-)

    If the system has a user interface the team will often draw an informal diagram depicting the navigation between these screens (boxes and lines).

    Later in the project these are formalised in a document with some supplemental text.

    I too favour agile lightweight approaches so I only document the area's of complexity within the project rather than every nut and bolt.

    You also asked about managing projects.

    I have been using iterative/incremental development cycles for some years and have worked in a number of agile environments. 

    Therefore, I feel comfortable with Scrum.  Documenting use requirements as stories, organising these into sprints and tracking remaining work with a product backlog have been effective for me.

    Finally, if the project encapsulates domain expertise you would probably want to take a domain driven approach.

    You may be interested in the below links;

    http://www.amazon.co.uk/UML-Distilled-Standard-Modeling-Technology/dp/020165783X
    http://en.wikipedia.org/wiki/Scrum_(development)
    http://agilemanifesto.org/
    http://domaindrivendesign.org/

    Hope this helps


    Pl mark as answer or helpful if you found this useful
    • Edited by G Moore Thursday, April 2, 2009 12:29 PM correcting grammar
    • Marked as answer by TyronGower Friday, April 3, 2009 10:05 PM
    Thursday, April 2, 2009 12:22 PM

All replies

  • The question for me deals with company politics, product features, timelines, frameworks, methodologies.

    Company politics:  How much documentation is required to tell everyone about the new project vs how much documentation is actually needed to get the job done.

    Product features:  Is the project/product super simple in that all features can be written on a sticky note or white board or are there so many complex inter-related features that you really need to create a proof of concept, various UML diagrams, software requirements specification (search google for this term and the .doc extension for the template).

    Timeline:  Do you have a year and a half to build the project where 6 months can be dedicated to documentation or do you have a month in which case I like to use SmartSheet.com to jott down my soft requirements for a quick sign off.

    Frameworks:  Can you use a pre-existing framework such as Microsofts Enterprise Application blocks, StructureMaps DI tool, LINQ to SQL or NHibernate data access, Dynamic Data Web Sites, .NET profiles, etc.  If so, some of the complexity is removed from your design and therefore so is the need to specify it.  Think black box.

    Methodologies:  Are you working in a fast paced "Agile" world where documentation is a bad word and forward motion is the keyword of the day or do you work in a lame old school way of thinking waterfall style world (guess which one I prefer?).  Agile tends to brag about less documentation but some is still a good idea!  If for nothing other than covering your butt when things don't quite work as well as others thought they should/would.  Waterfall generally requires you to describe every nut in the system (...to include the nuts thread type, whether it is coarse or fine, the type of metal used to create the nut, the weight of the nut, the shape of the nut, the direction to turn it when putting it on, which tool is used to put it on, which tool is used to take it off, how many turns to issue for proper usage, etc.....<agile just says get the nut that fits the bolt and tighten it>).  This comes down to are you building a financial application or an image gallery?  More complexity tends to work best with an appropriate amount of planning and documentation.

    Where do I start?  SmartSheet (or similar) and a white board session with everyone involved in the project.

    Oh and....C#!
    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    • Marked as answer by TyronGower Friday, April 3, 2009 10:05 PM
    Thursday, April 2, 2009 8:50 AM
  • UML is a popular way of communicating software models, so this is almost prerequisiste knowledge working in teams on large projects (assuming you're working in an object oriented language).

    When communicating a design you will probably want to use a mixture of UML and plain text to supplement the diagrams.  In the early stages of a project I use informal UML diagrams on a white board.  Often, I capture these using a digital camera and combine them in a document that is easily accessible to all stakeholders.  It's also easier to take to a meeting than a whiteboard :-)

    If the system has a user interface the team will often draw an informal diagram depicting the navigation between these screens (boxes and lines).

    Later in the project these are formalised in a document with some supplemental text.

    I too favour agile lightweight approaches so I only document the area's of complexity within the project rather than every nut and bolt.

    You also asked about managing projects.

    I have been using iterative/incremental development cycles for some years and have worked in a number of agile environments. 

    Therefore, I feel comfortable with Scrum.  Documenting use requirements as stories, organising these into sprints and tracking remaining work with a product backlog have been effective for me.

    Finally, if the project encapsulates domain expertise you would probably want to take a domain driven approach.

    You may be interested in the below links;

    http://www.amazon.co.uk/UML-Distilled-Standard-Modeling-Technology/dp/020165783X
    http://en.wikipedia.org/wiki/Scrum_(development)
    http://agilemanifesto.org/
    http://domaindrivendesign.org/

    Hope this helps


    Pl mark as answer or helpful if you found this useful
    • Edited by G Moore Thursday, April 2, 2009 12:29 PM correcting grammar
    • Marked as answer by TyronGower Friday, April 3, 2009 10:05 PM
    Thursday, April 2, 2009 12:22 PM
  • So, the tools help you with various aspects.  In general, there's still someone who thinks like you do (all in my head) about the project.  But with multiple people working on the project you have a few extra aspects to deal with.

    There are professional tools to help you just about all aspects of software development.  To name a few:
    • to share your designs with other designers or engineers. 
    • to share code and other project-related IP with other engineers.
    • to create and edit code and other project IP.
    • to debug and analyze software execution.
    • to document and clarify IP.
    • to analyze code and/or designs.
    • to facilitate meetings and exchange of information.
    • to track and manage resources and costs.
    • to make sure everyone is on the same page, and in sync (with respect to revisions of designs, revisions of code, revisions of hardware, etc.)
    • to test and track defects internally and externally
    • to deploy and distribute to customers
    • to interact with your customers after your software is deployed
    So to answer your question about , "how other people manage projects"...I would say that professional people take all these aspects of the project very seriously.
    Friday, April 3, 2009 4:24 PM