The intent of this study is to show an overview on which Software Development Lifecycles are being used at my company. I work for Telkom as a Senior Specialist – IT Strategy. The Telkom Group is the largest incorporate communications company in Africa. We provide incorporate ICT solutions to a broad scope of clients of across the African continent. The company ‘s vision is to go a universe category ICT supplier and key to this vision is client centricity. The company has in surplus of 22000 full clip employees and many different divisions and concern units with specialised focal point countries.
As such the Telkom Group does non hold a incorporate or individual Software Development Lifecycle method that it uses across the organisation. The development demands and demands of the different divisions and concern units vary. Some these concern units are internal facing and while others are client facing. There are elements of both in-house and outsource development throughout the organisation.
For the intents of this study I will concentrate on the development demands of one division in Telkom and the package development lifecycle that they use when developing and composing package. The division that I will concentrate on is called ITS – Flexibill. This squad of developers whose primary country of focal point is on the development demands of an application called Flexibill. The Flexibill platform is one of the most of import and concern critical applications in Telkom. It is the charge system that Telkom uses for all the merchandises and services it provides to its clients.
The package development demands
The Flexibill nucleus package faculties are non developed in-house by the ITS-Flexibill squad. It is an off the shelf Billing Solution for the Telecommunications environment that is supplied by a company called Amdocs. Amdocs is responsible for the nucleus package ascents and new package sweetenings and characteristics.
The development demands for Flexibill are extended and on-going. Several faculties of the Flexibill application had to be customized and rewritten to suit in with Telkom ‘s concern processes. Almost every other system in Telkom demands to interface with the Billing System. The dedicated development squad spends their clip composing bug holes, developing interfaces for other systems to incorporate into the charge platform and customizing and updating the merchandise catalogues on the charge platform when new merchandises and services are added.
Telkom uses the telecoms framework eTOM which is a usher for best concern patterns in the Telecommunication sector. The eTOM model advocates the usage of the FAB procedure ( Fulfillment, Assurance and Billing ) to take any merchandise to market. The usage of this procedure creates the bulk of the work for the Flexibill Development Team. For every new merchandise or merchandise alteration, the development squad demands to guarantee that the systems within the Billing Platform interfaces right with the systems in the Fulfillment and Assurance environments.
The Software development procedure
The ITS – Flexibill development squad follows the traditional theoretical account when developing codification for the Flexibill platform ; nevertheless Telkom uses as an overarching model called the Solution Value Chain ( SVC ) to direction the terminal to stop procedure for the merchandise or enhancement being developed from the clip the clip a concern demand emerges until that the demand is production ready. The package development lifecycle procedure which ITS-Flexibill squad uses for development is intertwined within the Solution Value Chain.
The Solution Value Chain – Overview
The intent of the solution value concatenation is to better the quality of the solutions delivered and to bring forth it more expeditiously and efficaciously. The solution value concatenation is made up of eight different stages.
A – Pre-Initiation Phase – In this stage the concern usually conceives an thought about a new merchandise or service that they want to establish based on market tendencies or client demands.
B – Initiation Phase – This is initial kick -off meeting where representatives from all the different squads that will be involved project meet. The new merchandise or service is presented to the squad and cardinal undertaking members are identified.
C – Planning and High Level Design Phase – The concern analysts are involved in this stage. All the concern demands are captured here.
D – Detail Design Phase – In this stage the designers, concern analysts and systems analysts design the terminal to stop solution. External sellers are besides invited at this phase. The hardware, package, web, application, runing systems and development demands are planned and designed.
E – Development Phase – This is the phase where the single constituents of the terminal to stop solution gets built. From a package development lifecycle position, this is the beginning of the SDLC.
F – Confirmation Phase – This were all the single constituents are integrated together to organize the terminal to stop solution.
G – Pilot Phase – In this stage the terminal to stop solution is rolled out to a limited figure of users to prove the characteristics, functionality and public presentation of the new system.
H – Rollout Phase – If stage G is successful, the merchandise is so rolled across the concern.
I – Handover Phase – Once the rollout has been completed, the new merchandise moves off from the undertaking stage and handed over to the operational staff for support and care.
Description of the package development procedure
The Software Design Life Cycle methodological analysis that is used by the ITS – Flexibill squad is the Waterfall Model. As indicated in Section 3.1, the over-arching model used is the Solution Value Chain. The Software development lifecycle starts at Phase E which is the development stage. Phase E as indicated in the solution value concatenation is non merely refers to package development but the development get downing point of all other constituents that make the terminal to stop merchandise. The solution value concatenation represents a horizontal flow of the full procedure and the Software Design Lifecycle is one of the perpendicular pillars that fit into the solution value concatenation.
4.1 Solution Value Chain and the SDLC
Integration & A ;
Operations & A ;
Solution Value Chain ( SVC )
4.2 SDLC – Waterfall Model Phases:
Requirements Analysis – all demands for the system to be developed are captured in this stage. The demands are a set of functionality and constants the terminal user expects from the system to be developed. These demands are captured from the terminal user through audience and proof procedure. A demands specification papers is created which serves as the guideline for the following stage of the theoretical account. Phase 1 of the SDLC procedure corresponds with Phase C of the SVC procedure. Phase C is much more generic and the demands assemblage is for the full solution. The Development Team representative go toing Phase B of the SVC procedure will do all the contacts required to garner information for Phase 1 of the SDLC.
System Design A- before coding it is of import to understand what is being created, what it does and what it looks like. The specifications papers from the first stage is carefully analyzed and system design is formulated. System design helps in stipulating hardware, systems demands and overall system architecture. The system design stage provides input into the following stage of the theoretical account through a system design papers. This stage besides corresponds with Phase D of the SVC. If the information gathered at Phase D of the SVC procedure is sufficient to continue with the coding so the procedure will go on.
Implementation – Once the system design papers is received, the work is divided into faculties. This when the cryptography starts. The system is foremost developed in little plans called units which are integrated in the following stage. Each unit is developed and tested for its functionality referred to as unit proving – unit proving verifies if the units meet their specifications. This stage is specific to the SDLC procedure is does non hold a corresponding stage in the SVC procedure.
Integration and Testing – in the old stage, each unit is designed and tested separately. In the integrating and proving stage all the single faculties co-ordinate between each other and it is so tested together as a complete system to guarantee that it behaves as per specification. After integrating and testing is completed the system is ready for bringing and usage by the client. Integration and testing in the stage is specific to SDLC part. Phase F of the SVC procedure besides has an component of integrating but this is the of the full solution. In Phase 4 of the SDLC the integrating is conveying the units that were developed separately together.
Operationss and Maintenance – this stage of the waterfall theoretical account is a virtually ne’er stoping stage. By and large jobs in the system are discovered during this stage. Most jobs are discovered after the systems are first deployed during the operations. The procedure to mend these jobs falls under the care part and may ensue in the same procedure being followed to repair the issues. This stage ties up back with the Handover Phase of the solution value concatenation, where the system is now in production and operational.
5. The activities in the procedure in footings of resources:
Because the Flexibill system is a really critical solution to Telkom, several environments have been created to guarantee that any alterations made to the production platform has been exhaustively tested and verified.
Telkom has three developments environments, a trial environment, a quality confidence environment, a pre-production environment and a production environment for Flexibill.
The development environments are built on practical platforms.
The developers composing codification on their personal computer and one time the codification is ready for proving, it is loaded on the development which is a reproduction of the production environment. The developers run their codification in this environment and make further analysis
The trial platforms are besides virtualized. The proving between multiple developer codifications takes topographic point here.
The QA environment is a scaly down version of the production environment. The environment is built on psychical hardware platforms.
All functional testing takes topographic point in this environment.
Once the developers are happy that the plan they written is working harmonizing to specifications, it is moved to the Pre-Prod environment.
The Pre-Production environment is an exact transcript of the Production environment. Load proving and existent universe simulations take topographic point in this environment.
Because the Pre-Production environment is an indistinguishable reproduction of the Production environment is dual as a Disaster Recovery platform.
All of the developers have high-end personal computer which they use for coding. Coding is done in Ocular Studio.Net and Java. All the beginning codification is stored in an application called CCC Harvest. The Flexibill platform itself runs on a combination Windows and UNIX. The backend database runs Oracle 10g which loaded on HP waiter run the UNIX runing system. The middleware and integrating beds besides run on UNIX waiters. The application and web waiter run on the Microsoft Windows waiters.
Flexibill is classified as a Class A system in Telkom. This system needs to hold a system handiness of 99.99 % uptime. As such there is a dedicated squad of about 25-30 staff members. About half of the squad is developers. Their functions vary from support and care to working in new undertakings. The balance of the squad consists of undertaking directors, concern analysts, system analysts and direction.
The developers are seasoned professionals and all are extremely skilled in either Ocular studio.Net or Java. The full squad has received project direction developing even though there are dedicated undertaking directors in the squad. The other accomplishments in the squad are those of the concern analysts and systems analysts.
5. Give an indicant of whether the package development procedure works good and whether all the stakeholders have buy-in to it?
The package development procedure for the ITS-Flexibill squad works good because it is non standalone procedure that merely the developer ‘s usage. It has been incorporated into a much larger model in which other function participants and stakeholders have input. Because of this over-arching model that encompasses the package development procedure, the other stakeholders have a position of what is go oning within the development environment. The advancement and position of development undertakings ever feedback up to the solution value concatenation so the stakeholders are happy with this procedure and support it.