SBM4201 System Analysis and Design: Gymnasium Management System
VerifiedAdded on 2023/04/17
|13
|1527
|469
Report
AI Summary
This report provides a system analysis and design for the Body Sculptors gymnasium, focusing on membership and facility management. It discusses the application of the Software Development Life Cycle (SDLC) with its six core processes: requirements gathering and analysis, design, implementation and coding, testing, deployment, and maintenance. UML diagrams, including class diagrams for the membership system and facility management system, and use case diagrams modeling the manager's staff roster scheduling and membership registration system, are used to model the system. The report also includes a PERT/CPM analysis. The analysis uses various techniques for requirements gathering, including case study review, interviews, and observation. Methodologies like Scrum are suggested for the implementation phase, along with testing strategies like unit, integration, system, regression, usability, and acceptance testing. The report concludes with deployment and maintenance considerations.
Contribute Materials
Your contribution can guide someone’s learning journey. Share your
documents today.

COVER PAGE
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.

Contents
1 Introduction..............................................................................................................................................3
2 Software Development Life Cycle (SDLC)..................................................................................................3
2.1 Requirements gathering and analysis................................................................................................4
2.2 Design................................................................................................................................................4
2.3 Implementation and coding...............................................................................................................5
2.4 Testing...............................................................................................................................................5
2.4 Deployment.......................................................................................................................................6
2.5 Maintenance......................................................................................................................................6
3 Class diagram............................................................................................................................................7
3.1 Membership system..........................................................................................................................7
3.2 Facility management System.............................................................................................................8
4 Use case diagrams....................................................................................................................................9
4.2 use case to model actors and use cases of the manager schedules staff roaster..............................9
4.2 Membership registration system.....................................................................................................10
5 PERT/CPM...............................................................................................................................................11
References.................................................................................................................................................13
1 Introduction..............................................................................................................................................3
2 Software Development Life Cycle (SDLC)..................................................................................................3
2.1 Requirements gathering and analysis................................................................................................4
2.2 Design................................................................................................................................................4
2.3 Implementation and coding...............................................................................................................5
2.4 Testing...............................................................................................................................................5
2.4 Deployment.......................................................................................................................................6
2.5 Maintenance......................................................................................................................................6
3 Class diagram............................................................................................................................................7
3.1 Membership system..........................................................................................................................7
3.2 Facility management System.............................................................................................................8
4 Use case diagrams....................................................................................................................................9
4.2 use case to model actors and use cases of the manager schedules staff roaster..............................9
4.2 Membership registration system.....................................................................................................10
5 PERT/CPM...............................................................................................................................................11
References.................................................................................................................................................13

1 Introduction
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.
2 Software Development Life Cycle (SDLC)
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
The diagram shows the representation of the stages making up the SDLC;
Figure 1: Diagramatic representation of the stages of SDLC
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.
2 Software Development Life Cycle (SDLC)
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
The diagram shows the representation of the stages making up the SDLC;
Figure 1: Diagramatic representation of the stages of SDLC

2.1 Requirements gathering and analysis
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.
2.2 Design
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.
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.
2.2 Design
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.
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.

2.3 Implementation and coding
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.
2.4 Testing
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.
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.
2.4 Testing
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.
2.4 Deployment
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.
2.5 Maintenance
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.
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.
2.4 Deployment
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.
2.5 Maintenance
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.

3 Class diagram
3.1 Membership system
3.1 Membership system
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

3.2 Facility management System

4 Use case diagrams
4.2 use case to model actors and use cases of the manager schedules
staff roaster
4.2 use case to model actors and use cases of the manager schedules
staff roaster

4.2 Membership registration system
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.

5 PERT/CPM
The time it will take to finish the whole project is 42 weeks going onwards with the maintenance.
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:
http://creately.com/blog/diagrams/use-case-diagram-tutorial/ [Accessed Mar. 29, 2019]
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:
http://creately.com/blog/diagrams/use-case-diagram-tutorial/ [Accessed Mar. 29, 2019]
1 out of 13
Related Documents

Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
© 2024 | Zucol Services PVT LTD | All rights reserved.