An Overview on Software Development
This article is specially meant for the beginners in software development project as an outsource service provider (OSP). And it is a slightly modified version of the classical sequential model that is appropriate for a lot of projects. And this model adapts it to the specific needs of real situations and convenience.
Measuring
Generally, Customers find it difficult to understand this phase. Vendors tend to supply you with an estimate itself, and that's it. Personally, I believe that customers may and should take more active part in the estimation process. For example, you have to be able to select from different options discussing the platforms, technologies, and tools that will be used for the target system. Never let the vendor baffle you with technical jargon and complex details. Also, make sure your vendor does a research of the existing libraries and tools that can be used in the project. Remember that an estimate should explicitly list what is included in the price, as well as why and how much any additional features will cost. Outsourcing is risky by nature, so you can't afford to take chances with a vendor like that. Finally, if you are in doubt about the provided estimate, consult an expert; if the vendor appears to try to take advantage of you, don't bargain with such a company. Just say "thank you" and look for another OSP. The estimate isn't the only document that results from this phase. The project contract (or project bid) and rough project schedule usually come into existence at this point, too.
Analysis
You view a big picture of the project and understand which steps need to be carried out by this system. This phase begins with analyzing what exactly you want to have done. You should determine and document the vision for the target product or system; the user profile(s); the hardware and software environment; the most important components, functions, or features the software must have; the security requirements, etc. To aid in the needs analysis, it is sometimes necessary to have prototypes created - or to have them created by professionals, for that matter. The product of this stage is the general system requirements. This document will be modified as the project is undertaken. All this can and often should be done in cooperation with your vendor and discuss about it well.
Specified Function
It is meant that what exactly the target system must do and the premises for its implementation. All requirements should be thoroughly defined and documented. The general system requirements and other documents created in the first phase serve as input here. So a specified function is necessary.
Coding with Testing
Transferring the specification algorithms into a programming language, your vendor creates and integrates the system components. The goal of this phase is building the target system based on the specifications developed in the previous phases. Performing code reviews and test cases worked out by the vendor's QA/QC division, as well as unit, integration, and system tests are other key activities of this phase. Comprehensive testing and correcting any errors identified ensures that components function together properly, and that the project implementation meets the system specification. This is One of the best ways to minimize the risk for you and your vendor is to have a project delivered and paid for in parts. In case of doubt, you can approach another vendor the specification and the code that was previously delivered. This will clear your anxieties and confusion.
Installation and further process
Release phase: Here, your vendor must transfer the target product or system to you. And the important activities usually include installation and configuration in the operational environment, acceptance testing, and training of the users if necessary. An important thing here is formal acceptance testing which comprises a series of end-to-end tests. It is performed to confirm that the product or system fulfills the acceptance requirements determined by the functional specification. And at the end, the product or system is considered formally delivered and accepted.
Software Architecture
Here it is necessary to determine the system components covering your requirements and the way these components will work together. The software architecture design may be logically divided into two parts: general design and detailed design.
The general design consists of the structural design, development strategy, and system design documentation. Working out the general design, developers break the target system into high-level components and describe them in the context of the whole system.
The detailed design is the specification and documentation on each component are developed.
Test Plan
The general system requirements, functional specification, and UI prototype serve as input for this phase. Completing this phase, your vendor should produce the description of the software architecture, the algorithmic structure of the system components and their specifications, the documentation of all design decisions, and a thorough test plan. It is the planning before beginning the program.
Maintenance
The task of this phase is the proper functioning of the software. The Operation and Maintenance phase begins once you have formally accepted the product or system delivered by the vendor. Software maintenance involves detecting and correcting errors, as well as extending and improving the software itself. It should be continuously maintained to improve a product or system.
UI Prototype
Creating a UI prototype in this phase is important for the success of the project. If your company has sufficient experience, you can have the functional specification and UI prototype created in-house. The development of the specification and UI prototype from your OSP is essential here. This will help you to check the vendor's expertise and at the same time, the vendor will have an opportunity to get a better idea of the project and get prepared for its implementation.This phase also create an exact project plan that contains the project schedule, milestones, and human resources. So it is convenient.
Conclusion
It can be concluded by stating that the system requirements, user manual, functional specification, and even software architecture design often need to be updated and modified throughout the course of the project implementation. Just be cautious that any changes introduced in the documentation are consistent with your initial vision for the target product or system. The phases should be tested well before installation.
