Who does what in a successful software development project?
DragonPoint’s software development methodology includes these steps, each performed by the right team member(s) for the job.
Requirements: Define the requirements in writing and with pictures that show you what system pages will look like.
Who: Requirements Analyst and/or Project Manager (PM) working with the client PM and subject matter experts
How: The business analyst or project manager meets with the client and listens, makes suggestions, and asks questions to clarify requirements. After meeting with the client, the PM or analyst numbers each requirement and writes the requirements document. Initially a mockup of every screen is included in the requirements, and later in the project, new screens may be mocked up or the document may reference another similar screen on which the new page will be based.
Weekly meetings with the PM and the client are used to continuously review progress to date, refine existing requirements and identify new ones, and discuss next steps. The PM keeps the client informed about the status of the budget and identifies out of scope tasks that require client approvals (and potentially, additional time and funding).
Failed projects: Verbal requirements are just suggestions that nobody can test against or measure as complete (or not). Expecting programmers to translate verbal requirements from the client into code is a recipe for disaster! Failed systems result from incomplete, vague, and/or inaccurate requirements.
Architecture: Similar to the way a construction architect develops blueprints for a building, a system architect designs the blueprint for the application.
Who: System Architects
How: The architect translates requirements into a technical blueprint for the system.
Failed projects: System architects have a special toolset; programmers who generally write reports or follow existing code patterns may be destined for failure when thrust into the role of a system architect.
Programming: Write the software.
Who: Programmers
How: Programmers use the tools and framework defined by the system architects and follow standards defined for the project to code the screens and functions described in the requirements document.
Programmers may specialize in one aspect of the application (sometimes called a layer of the system), such as the User Interface (screens) or database (where your information is stored), or they may be “full stack” developers, who code all aspects of a page or function, including getting the data for a page, coding the page and its business rules, and saving the data entered/updated on the page. Both approaches can be successful based on the skillset of the development team.
After programmers finish coding a unit of work, they test it and check it into source control, which is an important part of a project because it helps ensure that everyone working on the project is accessing the most current version of the code, and it also avoids overwriting work completed by one person with someone else’s code.
On a regular basis, programmers meet with the project manager to clarify requirements, report progress, and plan next steps.
Failed projects: There are lots of reasons why the programming part of a project fails. DragonPoint once took over support for a software project (after the sole developer died), and figuring out which version of the code to use was a nightmare because there were so many versions of the application, source control was not used, and it was very difficult to identify the production version of the code.
Other ways coding can sink a project include:
- Ignoring written requirements (or coding without them)
- Not following the system blueprint
- Getting the project 90% complete but never making it to 100%. Warning: if you keep hearing that your new software is 80-90% complete, you may need an intervention to get to 100%, because following the same process is not working.
Ready to take your software from concept to code? Contact DragonPoint to learn more.
