views:

100

answers:

4

What would you say are the development tasks for any given project? Say you are handed a functional spec for some sophisticated asp.net form to implement; what are the formal steps from specification to release?

I mean something in the spirit of:

  1. Get functional spec
  2. Identify business objects
  3. Create Flow chart
  4. Create data chart 5 ...

  5. Code the damn thing! :)

  6. QA ...

Unfortunately I have never ever used any formal approach - in all my jobs it has always been like "here's your spec, code it son" and i just went ahead coding UI, BO, data. But in this new project in the new startup with this new boss who has no knowledge of development process and wants to get an idea so he can define tasks for the outsourced team, he asked me to create a formal list.

Any comments are welcome!

Thank you, Andrey

A: 

This entirely depends on the type of the project that you handle.

This is an article that can help you with the different formal methodologies that you can apply in a development environment.

Software development methodology

rahul
+1  A: 

I personally prefer to follow the BDD, or Behavior Driven Design, methodology. BDD is another form of Agile and Test-Driven development, a little stricter in intent and process, that aims, like most other agile methodologies, to reduce waste and improve product quality. The beautiful thing about BDD is that it beautifully melds the tenets of Agile with the process of TDD via the concept of Specification.

The general approach is to start with a user story (aka placeholders for conversations). When you sit down with the appropriate parties to have those conversations, you develop one or more specifications. A specification defines the concern, the context within which the concern will be met, and the expected results, or observations, that a solution for that concern, within that contest, will generate. Specifications become tasks for the user story under discussion.

When the time comes to implement those tasks, you turn those written specifications into executable specifications via TDD, and create your code through a continuous, iterative verify-and-refactor process.

I could explain the process in detail, but the following article will cover it much better than I can:

http://www.code-magazine.com/article.aspx?quickid=0805061

BDD is a very modern, lean approach to software development. Decision is put off to the latest moment, and design takes place as the continual process of collaboration and iterative coding.

jrista
A: 

1) Identify an initial list of development tasks.

2) Identify which items are "too risky" and do some prototyping to remove risk around those tasks.

3) Identify tasks which are "too big" and do whatever is necessary to break those tasks into smaller tasks. I don't like to see any task bigger than 4 hours.

4) Estimate each task.

5) With the help of whoever is paying for the work to be done, get the tasks prioritized (it may make sense to do this before estimation if estimation itself is too large of a task and needs to be broken apart - in any case it's important to prioritize after estimation).

6) Identify the minimum amount of tasks required to hand off a "first release" of some sort that someone other than yourself can use.

7) Code and completely unit test each feature in order.

8) Deploy the code.

Development tasks can cover a wide spectrum of work other than writing code, like documentation, database design and implementation, third party integrations, vendor selections, etc.

Michael Maddox
A: 

Some tasks related to development. Definetly not a complete list. See Software Engineering methodologies (e.g. RUP, Agiles) and metrics (e.g. CMMI) for other kind of activities related to software engineering.

  • Task planning (includes estimation and timeline)
  • Environment setup (development environment, testing environment, integration environment, etc. - depending on the complexity of the project)
  • Status meetings (depending on the size of the team(s) )
  • Code review
  • Document review
  • Unit testing
  • Deployment
  • Issue evaluation (bugs, change requests, etc.)
  • Preparing releases (build, release notes)
  • Technical (architecture) and non-technical (user manual) documentation
  • Code documentation
Cătălin Pitiș