Featured Clients
Special : Single Page Website with 33% off, now only £99.99 more...
Vivo Systems have a variety of skills available to you for software development. Below is a feature list, if you like to find out more then please contact us.
We have experience in the following :-
Software Project Estimation; we've even written tools based on historical data to make our estimations more accurate.
Experience with various technologies and tools to get the job done quicker and to a high quality.
Requirements Capture techniques such as Use Cases and Functional / None Functional requirements...
Structured specification writing.
Systems analysis and design using object oriented design principles.
Programming and development using various languages and technologies.
Software testing with the use of various techniques such as white and black box testing, reviews and so on for integration, unit and system testing.
We do a range of maintenance work on contract bases for clients to update content or evolve a project over time.
We generally use the experience of our teams to aid in the software project estimation process but we also use an evidence based scheduling technique developed by one of our team members for their dissertation to estimate projects more accuracy. This increases our likely hood of developing a project on time, on budget and with the features you wanted. At times we also use techniques such as COCOMO and the work breakdown structure.
Requirements are about making sure systems come in on time, that the systems are reliable and most importantly meet the customers expectations (Kotonya, Sommerville, 1998).
We use varying techniques for requirements capture such as functional and none functional requirements, UML and so fourth. We understand that great communication and understanding of your problem and domain is vital for us to develop the system you want so finding out this information is key for us to do a great job.
The specification is abused in a lot of software engineering cases. We have found by experience that a document people can rely on for clarification speeds up our development as people know what it is they're doing and you know what we're doing. The most important part of the specification is that it aids design; We write a specification based on what we think you want, you look it over and ask us questions, any changes are amended and sent back, once you're happy with the specification at this stage is ready for systems analysis. The specification helps both parties clarify what is going to happen and the best way to do this which is why it helps design.
Systems Analysis is not 100% necessary but we sometimes use it to bring requirements and specification together in a more concise format, so it is is easier to design for and is also used to clarify requirements and uncover any missing requirements (Arlow, 2005). We're giving an object oriented example here : In some of our projects we've used a formatted document as the specification and Use Cases for the requirements, two orthogonal techniques. The aim of systems analysis from an object orientated perspective is to produce an analysis model by merging the requirements and specification. The focus is on what the system should do, not how, however the boundary between analysis and design can be ambiguous (Arlow, 2005). During systems analysis, a set of artefacts will be produced which will show a high level package diagram of the system.
System design provides a fairly high level of abstraction over the system, it shows key concepts and architectures. While the system design is not detailed it provides a level of understanding which allows our designed to design the system.
References
As a general rule of thumb we use the system design to identify the packages of the project, we then design these packages in iterations, each iteration is then coded and tested. The design again is at a high level and is generally a specification of interfaces / objects and their public and protected methods in object oriented terms. This level of design specifies what needs to be done and allows enough flexibility for the programmer to implement the solution to their part their way. Once coded the system is then tested and then the next iteration is done, all that changes now is integration testing and once everything is coded, systems testing. Whether we develop top down or bottom up depends on the project.
Depending on the client the acceptance policy will indicate how the system is tested with the clients and how payment will be handled, if it is on an iterative bases for example.
Maintenance for a software project can be handled in a number of ways but will be negotiated. It may be negotiated as part of the contract or not.
References
KOTONYA, G., SOMMERVILLE, I., 1998, Requirements Engineering : Processes and Techniques. John Wiley & Sons, Chichester.
ARLOW, J., NEUSTADT, I., 2005, UML 2 and the unified process. 2nd Ed. Addison Wesley.
