Everything You Always Wanted To Know About Software Development (But Were Afraid To Ask…) Part 2

Everything You Always Wanted To Know About Software Development (But Were Afraid To Ask…) Part 2

In our previous blog we ‘created’ a human algorithm that aggregated the most relevant questions clients ask when it comes to the initial stages of a software development project with yours truly. Now, in the second episode of this compelling box set blog blockbuster, (who knows where it will end?!) that same algorithm has got a taste for the action and wants to develop their own, bespoke application from scratch. Or do they…?

Read on for what happened next…

Q The app I want to develop has lots of different elements to it, is it best to start from scratch or interface with existing apis?

A We'd need to look at both options.  Firstly we'd need to get better idea of your requirements and go in to a lot more detail about all of the different elements.  We could then review what's out there (if you haven't already done this), to see if there are tools/services that meet some or all of your requirements.  If there is nothing, then we'd need to create everything from scratch, however it's possible that it could be a combination.  For example, you may decide to create your core functionality from scratch, and then use existing tools/services to offer some of the less important functionality.  This then allows your to focus your investment on the important stuff  that really gives you the value you're after.

Q We want to measure in areas such as mental and physical health - so it will need a survey element. Can we get context on the results and aggregate individual and collective outcomes using the data collected?

A Once you have collected the data in the necessary format, it's then available to summarise, aggregate, report on as you need.

Q What would your process look like for the initial phase?

A Basically, we'd need to find out as much information from you about your requirements as we can.  So initially we'd ask lots of questions and go in to details about things such as who would be using the software, what tasks they would need to perform, what other stakeholders there are in the project, what you're trying to achieve etc.  We'd then create a document summarising our understanding and proposing the next steps.

Q What would be the list of actual Deliverables?

A The ultimate and key deliverable, of course, is the software itself.  We would aim to deliver working versions of the software early and often, adding extra (or modifying existing) functionality at regular intervals.  Ultimately it is only this that truly demonstrates that we've understood what your requirements correctly and have translated that into something that gives you what you want and delivers you value.

However, depending on the size of the project there may well be other deliverables at various stages of the project.  E.g. Some form of requirements documentation, project plan, diagrams, test plans, unit tests, user interface designs/mockups…

The full list would depend very much on the size of project and your requirements.

Q What Quality Assurance process do you follow?

A Technically we have coding standards and practices which we use whilst developing code.  We create unit tests as part of the development process which automatically test aspects of the code.  We have a Sprint workflow process that includes internal testing and QA of development followed by client acceptance testing and review. 

Q  What about your maintenance process? What is that usually like?

A We offer a 3 month free support for bugs after completion of development.  This can be extended depending on support packages.  We offer tailored support packages for each product after completion.  All systems are developed with error logging and notifications that are monitored by us as part of the maintenance process.  Ongoing package upgrades and other services are available as part of the maintenance packages.  

Q How would you consider this project a success from your side and how do you measure that internally against the brief?

A Technically measured on delivery against use cases and user stories from the specification but mainly on customer satisfaction at sprint reviews and final delivery.

As part of the project we can develop a set of measurable success criteria in conjunction with the client and can use these at various stages of the project and at final completion to make sure we've met what was expected of the project.

Ultimately the success is measured by a happy customer who wants to continue working with us on an ongoing basis.

Author

Gary Pleece

comments powered by Disqus