History of System Development Life Cycle - SDLC
Version 5 | Current version | |
---|---|---|
Also know as System Design Life Cycle and Software Development Life Cycle, WikiPedia's definition of SDLC is "the process of developing information systems through investigation, analysis, design, implementation and maintenance". To reiterate the major concept, there are the following phases (some of which overlap during the cycle): Feasibility StudyA documented concensus that the project or upgrade requested will be successful for the effort involved. An objective or group of objectives should be understood prior as the root of the analysis. Aspects such as cost (time, money, effort), other alternatives, and constraints on existing and future solutions, should be investigated and documented.Analysis and SpecificationsThis is to analyse the existing and proposed needs of the end users, detailing them to be used as cornerstones of design and testing.Design, Documentation and Quality AssuranceBased on the agreed upon specifications, design objectives will be clearly defined. As the design is finalised, this will be used as the basis for User and Technical documentation. Quality Assurance such as automated testing can be catered for in the design. Overall a more focused effort is possible during the design of the system. Prototyping and use of programming stubsDevelopmentApart from coding, items such as Change Control and policies for Third Party Library dependencies should be considered.Systems ImplementationSystems Maintenance | Also know as System Design Life Cycle and Software Development Life Cycle, WikiPedia's definition of SDLC is "the process of developing information systems through investigation, analysis, design, implementation and maintenance". We currently have an attempt of a simple SDLC which tries to cover everything, but I believe tied in with Package Maintainer Teams, we could have an SDLC for the core and on a per package basis. To reiterate the major concept, there are the following phases (some of which overlap during the cycle): Feasibility StudyA documented concensus that the project or upgrade requested will be successful for the effort involved. An objective or group of objectives should be understood prior as the root of the analysis. Aspects such as cost (time, money, effort), other alternatives, and constraints on existing and future solutions, should be investigated and documented. At this point, it should be determined whether the project should continue or not.Analysis and SpecificationsThis is to analyse the existing and proposed needs of the end users, detailing them to be used as cornerstones of design and testing. Criteria of a successful implementation should be agreed upon, along with functional requirements. This can be done through process flowcharts and data flow diagrams. Reuse of Third Party code (libraries and/or projects) should be identified if cost-effective (time, money, effort). Systems development goals, costs, and deliverables expectations should be identified and documented.Design, Documentation and Quality AssuranceBased on the agreed upon specifications, design objectives should already be clearly defined. As the design is finalised, this design information will form the basis for User and Technical documentation. Quality Assurance such as automated testing can be catered for during the design stage. Prototyping and use of mock function stubs (see StubsAndMockObects) allow rapid development of users interfaces and class design, which will form the basis of QA testing suites.DevelopmentApart from coding, items such as policies for Change Control and Third Party Library and Code dependencies should be considered. Several iterations of program and testing should be planned and milestoned tentatively. Testing duties should be segregated from development tasks as much as possible to ensure fair analysis. User interfaces, test data for objectives testing and initial systems documentation should be produced now.Systems ImplementationImplementation and production deployment is planned here (not applicable to our project). File conversion, migration and upgrade paths should all be catered for here, using pilot, parallel or full-system cutovers. User and operations manuals should be complete.Systems MaintenanceThis consists of routine maintenance and bug-fixes, with scheduled improvements prepared over time using mini-SDLC's. Periodic assessment of design and performance based on the needs and changes also occurs. |