Electronic Cash News

What is the difference between a software designer, software engineer, programmer and software developer? The short answer for figuring out a software development job title is to read the associated job description. Companies can provide a wide variety of job descriptions for the same software development job title. Some companies are very definitive in determining job titles versus other companies may use job titles loosely. I would think that a well-defined software development job title would be aligned with the software development life cycle (SDLC). For example:

- architect / designer - would be involved with requirements and specs.

- programmer - large company - coding; small company - does all development

- engineer - broad term, but follows well-established SDLC processes and standards (i.e. not an “artist” or one-man show)

- developer - broad term, but person can do coding

Links: Software Engineering WiKi Page, Software Development Wiki Page

Agile methodologies definitely improve communications between developers, business leads, and stakeholders in terms of project success compared to “traditional” waterfall methods. This is true no matter where the coders are located or whether they are an outside vendor or not(I have not seen too many projects succeed that used the waterfall method).

Yes, I think it is key that you share your product backlog / prioritized task list with outside vendors that are working on your software product. That way they have more opportunity to anticipate your needs and see what work is probably coming their way in the coming weeks and months.

Every project is different, but in many cases it is best to gather and refine functional requirements in stages based on an initial charter document. For a large project the project lead should either identify or create some type of charter document that outlines the project’s purpose, scope, major deliverables / milestones, and a high-level cost estimate.

Instead of trying to identify all the functional requirements upfront, break the project into chunks. In build 1 define the functional requirements for a pilot project that keeps the users and stakeholders fully engaged in validating and refining the functional requirements. In each requirements and design phase as well as subsequent software builds, continue to work with stakeholders to update the overall functional requirements and review the charter document to assure project is on track.

The functional requirements should be definable, attainable, and decisive (i.e. link back to the project charter document and specific enough to guide software development). This allows the functional requirements to be traceable in that they can be measurable and be used to guide user acceptance testing and approving software for production.