SDLC: An Overview
This report discusses the system analysis process of the Body Sculptors gymnasium which is currently using a computer-based information system to monitor and track membership and member activities in the gymnasium. The report discusses how the six core process of the software development life cycle (SDLC) are applicable in the development of the proposed system. To model the system, UML diagrams are used.
SDLC can be defined as a framework that defines or specifies steps that are followed while developing a software. SDLC covers on the details of the plan for building, deploying and performing maintenance on a software. Following all stages of the SDLC helps achieve a systematic process of developing the software. SDLC was developed with the main goal being to develop a high quality at the end of the process. The following are the 6 stages of the SDLC;
- Requirements gathering and analysis
- Design
- Implementation and coding
- Testing
- Deployment
- Maintenance
This is the first phase of the software development life cycle. At this stage of the process, requirements of the system being developed are collected and analyzed. Collection of requirements is done through a process called requirements engineering where the project manager together with the project team organize meetings with the customer to gather all information about the system. There are various methods that are used for requirements gathering but perhaps the most common and the most applicable for the proposed Body Sculptors gymnasium information system are;
- Case study review- This method of requirements gathering involves analyzing the case study with the details of the business operation. The requirements gathering team goes through the case study analyzing all information and presents its finding it terms of requirements to the project manager.
- Interviews- conduction of interviews is another efficient and costly method of requirements gathering. Interviews are conducted to the customer of the business. The interviews can involve one or more employees working in the organization to get their view of how the system is supposed to help them and this is analyzed to come up with a set of requirements. There are three types of interviews; structured interviews, unstructured interviews and semi-structured interviews. Structured interviews follows a specific structure where by the interviewer follows a set of questions which are answered by the interviewee and both parties are not supposed to deviate from the set of questions. Unstructured interviews do not follow any structure and the interviewer does not necessarily need to have interview questions. The interview is open and both parties can deviate as much as they want. Semi-structured is a combination of structured and unstructured interviews. In semi-structured interviews, the interviewer follows a set of questions but both parties are allowed to deviate from the list of interview questions. Semi-structured interviews are the best especially for the recommended system because they will make analysis of the results easy as well as help gather all possible requirements from the interviewees.
- Observation- Observation is one of the cheapest requirements gathering technique. This can be done by sending the requirements gathering team to the business premises of the customer where they are supposed to engage themselves in the day to day running of the business while at the same time gathering requirements on the business operations.
The recommended technique for the proposed system is using a combination of the three techniques because this will ensure that all requirements are gathered and there exists no doubt between the customer and the project team. After the requirements are collected, they are analyzed by the project team and a software requirements specification document is produced.
This is the next stage in the SDLC after requirements gathering and analysis. This stage uses the software specifications document achieved in the previous state. The document is analyzed and used to define the architecture of the system. Common techniques that are used in this stage of the SDLC include use of wireframes to define the design of the system. UML diagrams are also to model the design of the system (Nishadha, 2015). Story boards are also used to illustrate how the design meets the functional requirements of the customer. At the end of this stage, a software design document (SDD) is produced.
After finishing the design stage and producing a software design document, the development team is now ready to start developing and coding the system. The development team implements all components of the software at this stage (Langer, 2007). There are different methodologies that are used at this stage including scrum, unified programming and extreme programming. For the proposed project, the best methodology to use to develop the system is using scrum. Scrum enables developers to divide the development tasks in smaller tasks and the smaller tasks into even smaller tasks called sprints (Lonergan, 2015). The smallest tasks are then divided upon the development team. A team member picks the sprint that is he can manage thus the name scrum. At the end of the day the development team is supposed to have small meetings where each of them discusses the progress of their sprint. A sprint typically takes about a week. At the end of the development process, the development team presents the final version of the system. Using Scrum will require a versioning system like GIT to track the different versions of the system achieved at the end of each iteration.
The Software Development Life Cycle (SDLC)
After the development team is done with implementation and coding, the system is now ready for testing. Testing involves testing all aspects of the system to make sure that all functional and non-functional requirements have been met. There are different types of tests that are performed on the system including;
- Unit testing
Unit testing involves testing every unit before it is integrated with other units to form a component. In agile using scrum approach, the unit can be the sprints allocated to every team member which have to be tested before integration is done.
- Integration testing
Integration testing is testing on the integration of units to make sure the units have been integrated successfully without any error. For example integration testing between two methods communicating between themselves can involve testing the parameters to determine of the data passed matches with the type of parameters.
- System testing
System testing involves testing the whole system for bugs. Testing is done on all components to make sure that they have been integrated properly to from the whole system.
- Regression testing
Regression testing involves running the system through tests to identify bugs. Regression testing is testing the system to fail so that the bugs can be identified before the system is deployed. Regression testing can be simulated with actual user data to see if the system will pass all the tests.
- Usability testing
Usability testing is testing done to see whether the system is usable to the end users. Usability testing can use real users who will be using the application as subjects who will be using the application as a beta.
- Acceptance testing
Acceptance testing is done with the customer where by the customer is involved in testing of the product to give his verification on whether the end product meets his initial requirements.
After the product is fully tested, the system is now ready to be deployed. Deployment of the system is done after user acceptance testing where the customer approves the product. The software is either deployed on premise or off-premise from the customer’s business premises. After deployment, the customer can start using the system.
After the system is deployed on the production environment, maintenance of the product starts. Maintenance is done when bugs are detected while the system is in use or when necessary updates are needed which are deployed as patches. Maintenance of the product goes on for a long time after the product is deployed.
The time it will take to finish the whole project is 42 weeks going onwards with the maintenance.
References
Langer, A.M., 2007. Analysis and Design of Information Systems Third Edition., New York: Springer.
Lonergan, K., 2015. Example Project risks – good and bad practice: PMIS. Available at: https://www.pmis-consulting.com/example-project-risks-good-and-bad-practice/ [Accessed August 16, 2017].
Nishadha, 2015. Use Case Diagram Tutorial ( Guide with Examples ). Creately. Available at: https://creately.com/blog/diagrams/use-case-diagram-tutorial/ [Accessed Mar. 29, 2019]