SYSTEM ANALYSIS & DESIGN Assignment Higher Nationals Internal verification of assessment decisions – BTEC (RQF) INTERNAL VERIFICATION – ASSESSMENT DECISIONS Programme title HND in Computing Assessor Unit(s) Assignment title Internal Verifier Unit 34: System Analysis & Design Automated system for E-Solutions Private Limited Student’s name List which assessment criteria the Assessor has awarded. Pass Merit Distinction INTERNAL VERIFIER CHECKLIST Do the assessment criteria awarded match those shown in the assignment brief? Y/N Is the Pass/Merit/Distinction grade awarded justified by the assessor’s comments on the student work? Y/N Has the work been assessed accurately? Y/N Is the feedback to the student: Give details: • Constructive? • Linked to relevant assessment criteria? • Identifying opportunities for improved performance? • Agreeing actions? Y/N Y/N Y/N Does the assessment decision need amending? Y/N Y/N Assessor signature Date Internal Verifier signature Date Programme Leader signature (if required) Date Confirm action completed Remedial action taken Give details: Assessor signature Date Internal Verifier signature Date Programme Leader signature (if required) Date 1 Higher Nationals - Summative Assignment Feedback Form Student Name/ID Unit 34: System Analysis & Design Unit Title Assignment Number 1 Assessor Submission Date Date Received 1st submission Re-submission Date Date Received 2nd submission Assessor Feedback: LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis methodologies Pass, Merit & Distinction Descripts P1 M1 D1 LO2 Produce a feasibility study for a system for a business-related problem Pass, Merit & Distinction Descripts P2 M2 LO3 Analyse their system using a suitable methodology. Pass, Merit & Distinction Descripts P3 M3 D2 LO4 Design the system to meet user and system requirements. Pass, Merit & Distinction Descripts Grade: P4 M4 Assessor Signature: Date: Resubmission Feedback: Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date: * Please note that grade decisions are provisional. They are only confirmed once internal and external moderation has taken place and grades decisions have been agreed at the assessment board. 2 Pearson Higher Nationals in Computing Unit 34: Systems Analysis & Design Assignment 01 3 General Guidelines 1. A Cover page or title page – You should always attach a title page to your assignment. Use previous page as your cover sheet and make sure all the details are accurately filled. 2. Attach this brief as the first section of your assignment. 3. All the assignments should be prepared using a word processing software. 4. All the assignments should be printed on A4 sized papers. Use single side printing. 5. Allow 1” for top, bottom , right margins and 1.25” for the left margin of each page. Word Processing Rules The font size should be 12 point, and should be in the style of Time New Roman. Use 1.5 line spacing. Left justify all paragraphs. Ensure that all the headings are consistent in terms of the font size and font style. Use footer function in the word processor to insert Your Name, Subject, Assignment No, and Page Number on each page. This is useful if individual sheets become detached for any reason. Use word processing application spell check and grammar check function to help editing your assignment. Important Points: 1. It is strictly prohibited to use textboxes to add texts in the assignments, except for the compulsory information. eg: Figures, tables of comparison etc. Adding text boxes in the body except for the before mentioned compulsory information will result in rejection of your work. 2. Avoid using page borders in your assignment body. 3. Carefully check the hand in date and the instructions given in the assignment. Late submissions will not be accepted. 4. Ensure that you give yourself enough time to complete the assignment by the due date. 5. Excuses of any nature will not be accepted for failure to hand in the work on time. 6. You must take responsibility for managing your own time effectively. 7. If you are unable to hand in your assignment on time and have valid reasons such as illness, you may apply (in writing) for an extension. 8. Failure to achieve at least PASS criteria will result in a REFERRAL grade . 9. Non-submission of work without valid reasons will lead to an automatic RE FERRAL. You will then be asked to complete an alternative assignment. 10. If you use other people’s work or ideas in your assignment, reference them properly using HARVARD referencing system to avoid plagiarism. You have to provide both in-text citation and a reference list. 11. If you are proven to be guilty of plagiarism or any academic misconduct, your grade could be reduced to A REFERRAL or at worst you could be expelled from the course 4 Student Declaration I hereby, declare that I know what plagiarism entails, namely to use another’s work and to present it as my own without attributing the sources in the correct form. I further understand what it means to copy another’s work. 1. I know that plagiarism is a punishable offence because it constitutes theft. 2. I understand the plagiarism and copying policy of Edexcel UK. 3. I know what the consequences will be if I plagiarise or copy another’s work in any of the assignments for this program. 4. I declare therefore that all work presented by me for every aspect of my program, will be my own, and where I have made use of another’s work, I will attribute the source in the correct way. 5. I acknowledge that the attachment of this document signed or not, constitutes a binding agreement between myself and Pearson , UK. 6. I understand that my assignment will not be considered as submitted if this document is not attached to the assignment. Student’s Signature: (Provide E-mail ID) Date: (Provide Submission Date) 5 Higher National Diploma in Computing Assignment Brief Student Name /ID Number Unit Number and Title Unit 4: Systems Analysis & Design Academic Year 2021/22 Unit Tutor Assignment Title Automated system for E-Solutions Private Limited Issue Date Submission Date IV Name & Date Submission format The submission should be in the form of an individual written report written in a concise, formal business style using single spacing and font size 12. You are required to make use of headings, paragraphs, and subsections as appropriate, and all work must be supported with research and referenced Please provide in-test citations, reference list and bibliography using Harvard referencing system. Please also provide a bibliography using the Harvard referencing system. The recommended word limit is not less than 5000 words, although you will not be penalised for exceeding the total word limit. Unit Learning Outcomes: LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis methodologies. LO2 Produce a feasibility study for a system for a business-related problem. LO3 Analyse their system using a suitable methodology. LO4 Design the system to meet user and system requirements. 6 Assignment Brief and Guidance: *Please note that assignment guidance is for reference only and should be more specific in detail to meet customized needs. Assignment brief Case study The new automated system is designed to replace the current, manual, error-prone process of E-Solutions private Limited. The automation of existing process is to reduce the company’s expenses and enhance the productivity significantly. This transformation also would support for: 1) Successful teams working 2) Completing projects on time and within budget due to a better understanding of system requirements and tasks to be completed 3) Starting projects on time through automated project scheduling system. In the proposed system, the Project director creates a project and a “project profile” for each project. The creation of the project profile includes identification of project employee costs, the assignment of tasks to the project, and the assignment of a project manager. The project profile is consisted of project id, project personnel cost, a list of tasks assigned, and the project manager. The Project director also creates the teams for a given project, assigns employees to the teams, and assigns a team leader. The Project manager is responsible for assigning tasks to various teams working on the projects(s). The Team Leader assigns tasks to the team members. Additional functionality includes: 1. Produce and update information about different software projects, project teams, specific team member assignments and team skills. Perform function point analysis to identify the personnel cost of the project and provide information to generate invoices upon completion of project phases. Monitor projects and identify completed tasks and ongoing tasks of each project. 7 Activity 01 Discuss traditional and agile system analysis methodologies used in the industry by comparing and contrasting the strengths and weaknesses of them. Critically evaluate two methodologies by referring to the examples to support your answer. Activity 2 Produce a feasibility report for the scenario given above and assess the importance of feasibility criteria used for the system investigation. Critically evaluate the strengths and weaknesses of feasibility study with relevant to the proposed solution. Activity 3 Analyse and review the system requirements of the proposed solution given in the scenario using a suitable methodology. Functional and non-functional requirements of the system should be clearly mentioned. Assessment of the effectiveness and suitability of the chosen methodology should be provided with proper justifications. Activity 4 Produce a system design specification for the above scenario and assess the effectiveness of your design and the methodology used with reference to how it meets the user requirements. Your system design specification should include architectural design, interface design, database design, and program design. 8 Acknowledgement Working on this assignment has been an amazing, thrilling, sometimes difficult, but always fascinating experience. This work would not have been accomplished without the help of several people. First and foremost, I would want to convey my heartfelt gratitude to my lecturer, Ms. Prasadini. This work cannot be completed successfully without her supervision and cooperation. And I would wish to take this opportunity to thank my institute, ESOFT Metro Campus, for providing us with the required resources. I would especially want to thank my parents, family members, and friends, all of whom I hold in high respect, and I would like to express my heartfelt gratitude to everyone who has assisted me. 9 10 1.1 What is System Analysis and Design? 1.1.1. A System A system is made up of several interconnected or interacting parts that behave in a predetermined way to generate a coherent whole. A system's limits, structure, and purpose, as well as how it functions, all depend on and are influenced by its surroundings. 1.1.2 System Analysis It is a procedure for gathering and analysing data, determining the issues, and breaking down a system into its constituent parts. System analysis is done to investigate a system or its components in order to pinpoint its goals. It is a technique for solving problems that makes the system better and makes sure that all of its parts function effectively to serve their intended purposes. Analysis outlines the system's actions. 1.1.3 System Analyst In information systems development initiatives, the system analyst is significant. In order for the team to design the correct system in an efficient manner, the systems analyst collaborates closely with every project team member. System analysts need to be tech-savvy in order to address business issues. Systems analysts can also act as change agents by determining the organizational improvements that need to be made, designing the systems to carry out those changes, and inspiring people to adopt the systems. This individual builds the brand-new information system and makes sure that all IS standards are upheld while also coming up with ideas and proposals for how IT may support and enhance business operations that are backed by IT. The system analyst will have extensive training, experience, and programming knowledge. 11 Fig 01: System Analyst 1.1.4 Systems Design Planning a new business system or updating an existing system involves describing its modules or components to meet the necessary requirements. Prior to making any plans, it is important to thoroughly study the current system and discover the most effective ways to use computers. The goals of the system are the key focus of system design. System Analysis and Design mainly focuses on; a. Systems b. Processes c. Technology 1.2 System Development Life Cycle 1.2.1 What is SDLC? A conceptual model for project management known as the systems development life cycle (SDLC) details the phases of an information system development project, from the early phase of a feasibility study to the ongoing maintenance of the finished application. Both technical and non-technical systems can use SDLC. A system is typically an IT technology, including 12 hardware and software. Standard SDLC participants include system and software engineers, development teams, and end users. Project and program managers are also frequently present. Fig 02: System Development Life Cycle Every piece of hardware or software will go through a development process, which is a series of processes that can be thought of as iterative. The SDLC is used to provide a strict framework and structure to specify the stages and steps required in system development. 1.2.2 Steps of the SDLC There may be several steps in an SDLC. There aren't any certain, predetermined steps. The typical number of steps is 7 or 8, but there can be anywhere from 5 to 12. 1. Gathering Requirements In order to create a product that meets the needs of the consumer, all necessary information is gathered from them during this phase. Any questions must be answered during this specific time. 13 Fig 03: Gathering Requirements 2. Analysis A meeting is scheduled with the client by the business analyst and project manager to obtain all the necessary information, such as what the client wants to construct, who will be the end user, and what the product's purpose is. A fundamental knowledge or understanding of the product is crucial before building it. 3. Design The requirements acquired in the SRS document are utilized as an input in this phase to determine the software architecture needed to implement system development. 4. Development The moment the developer receives the design document, implementation and coding begin. The source code is converted from the software design. During this phase, the entire software is implemented. 5. Testing As soon as the code is finished and the modules are made available for testing, testing begins. The software is rigorously evaluated in this phase, and any flaws are assigned to developers to be corrected. Retesting and regression testing are carried up up till the program meets customer expectations. To ensure that the program meets the requirements of the customer, testers consult the SRS document. 6. Deployment 14 Depending on the customer's expectations, the product may first undergo UAT (User Acceptance Testing) before being deployed in the production environment. 7. Maintenance After a product has been deployed in a production environment, the developers are responsible for maintaining the product, taking care of any issues that need to be resolved or enhancements that need to be made. 1.3 System Development Methodology System development methodology is a framework used in software engineering to organize, plan, and manage the design of information systems. System development methodologies are recommended as a way to enhance the management and control of the software development process, structure and optimize the procedure, and standardize the development process and end product by defining the tasks to be completed and the methods to be applied. There are two main types of system development methodologies. They are; 1. Traditional 2. Agile Fig 04: System Development Methodologies 15 1.3.1 Traditional System Development Methodology Software development lifecycle stages and phases are the foundation of conventional software development approaches. Requirements lead to design, which leads to development, which leads to testing, which leads to maintenance in this situation. Waterfall, Iterative, Spiral, and V-Shaped are the most commonly used traditional Software Development Lifecycle models. 1.3.1.1 Waterfall Model The systems development life cycle model for software engineering is widely used, and it uses the waterfall approach. The waterfall model defines a way of development that is linear and sequential and is frequently recognized as the traditional approach to the systems development life cycle. Fig 05: Waterfall Model 1.3.1.1.1 Phases of Waterfall Model 1. Requirement Gathering and Analysis The business analyst gathers the requirements at this phase, and the team thereafter evaluates them. During this phase, requirements are documented, and clarifications might be requested. The project team requires answers to the following questions, which were not addressed in the requirements document, after going over and reviewing the requirements. 16 Will the new banking app be utilized internationally? Should we support multiple languages? How many users can be expected for the app? 2. System Design Working on the project's software architecture, high level and low level designs are the architect and more seasoned team members. In order to ensure that the system is always accessible, it is decided that the banking application needs redundant backup and failover capabilities. High level and low-level design documents are produced by the architect. 3. Implementation The project's coding is done by the development team. They use the design artifacts or documentation to make sure that their solution adheres to the architecture's finished design. They include a number of security checks and audit logging capabilities in the program because it is a banking application and security was a top priority in the application requirements. They also carry out a variety of other tasks, such as having a senior developer check the code of the junior developers for errors. The code is statically analyzed by some developers. 17 4. Testing The testing team runs through the entire application and looks for any bugs. The testing team tests the fixes to make sure the faults are fixed after the developers have fixed them. To test the application from a domain viewpoint, testers with experience in the banking industry were also employed for the project. Teams of security testers were tasked with evaluating the banking application's security. 5. Deployment On the servers that were purchased for the banking application, the team constructs and installs the program. The installation of the OS on the servers, the application of security patches, the hardening of the servers, the installation of web servers and application servers, the installation of databases, etc. are some examples of high-level tasks. To get the application functioning on the production servers, they also coordinate with network and IT administrative departments, among others. 6. Maintenance The team makes sure the application is operating faultlessly on the servers with no downtime during the maintenance process. After becoming live, issues that are reported are repaired by the team and tested by the testing team. 1.3.1.1.2 Advantages of Waterfall Model: This model is clear, understandable, and practical. Because of the rigor of the model and the fact that each phase has a set of outcomes and a review process, it is simple to manage. 18 This model processes and completes steps one at a time. Phases do not even cross over. For smaller projects with well-defined and well-understood needs, the waterfall approach is effective. 1.3.1.1.3 Disadvantages of Waterfall Model: It is quite challenging to go back and update something that was badly executed during the concept stage once an application is in the testing stage. It takes till the end of the life cycle for any working software to be generated. Risk and uncertainty are very high. Unsuitable as a model for complicated and object-oriented projects. Ineffective model for continuing, protracted projects. Not appropriate for projects where there is a moderate to high probability of requirements changing. 1.3.1.1.4 When to use Waterfall Model: Only when the needs are clearly visible, well-defined, and fixed is this model applied. Definition of the product is stable. Technology is comprehended. No unexplained requirements exist. There are many resources and experts available for free. The undertaking is brief. 19 1.3.1.2 Prototype Model A prototype is produced, tested, and then revised as necessary under the prototyping model, a systems development approach, until a suitable prototype is eventually achieved from which the whole system or product may now be developed. Fig 06: Prototyping Model 1.3.1.2.1 Phases of Prototyping Model Requirements gathering and analysis Details of the system's requirements are defined. Design A brief design or a preliminary design. It provides the user with a quick overview of the system. Quick designs facilitate the creation of the prototype. Prototyping Actual prototypes are created using the data acquired during quick design. It is a scaled-down version of the necessary system. 20 Customer Evaluation A developed prototype is demonstrated to the client for a first inspection. Review and Updation If the user is dissatisfied with the existing prototype, it needs to be improved in accordance with their feedback and ideas. A final system is created based on the final prototype that has been accepted once the user is satisfied with the developed prototype. Implement Product and Maintain After comprehensive testing, the final system is placed into production after being created based on the final prototype. 1.3.1.2.2 Advantages of Prototyping Model: Lower costs and time: - The quality of the requirements and specifications given to clients is improved through prototyping. Customers can predict greater expenses, necessary adjustments, significant project roadblocks, and most crucially, potential disastrous final results, with prototyping. For years to come, good prototyping can guarantee product quality and cost savings. User engagement has improved and grown: - Most clients want to feel like they are involved in all the minute details of their project. Users can see and engage with a functioning model of their idea through prototyping, which calls for their participation. Customers can adjust model specifications, request project revisions, and provide fast feedback when using prototypes. Most significantly, prototyping 21 helps prevent misinterpretations and misunderstandings during the development process. Reduced expenses and time: - Projects that are completed on time and under budget are always a hit with clients. The criteria and specifications that are given to clients are of higher quality because of prototyping. Implementing changes that are discovered later in development is significantly more expensive. With fast and less expensive software, prototyping enables you to determine early what the end user wants. 1.3.1.2.3 Disadvantages of Prototyping Model: Time-consuming: - Creating the prototype model takes a lot of time. Multiple prototypes are tested before the final product is developed, which takes a lot of time. Inaccurate assumption regarding the delivery of the finished item: - At a very early stage, the customer has direct touch with the prototype. The buyer might assume that the real product will also arrive early as a result, which could result in confusion. Sometimes, this may not be the case. Make poor decisions: - The creator is always concerned with the quality of their creation. However, they could make poor choices about the 22 prototype's quality while rushing to create it, which could have an impact on the final product. Misunderstandings about the finished product: - Customers may become annoyed and frustrated with the prototype model and lose interest in the final product. Customers may believe that the final version will have the same flaws even though it is enhanced and refine. 1.3.1.3 Spiral Model One of the most significant models for the Software Development Life Cycle that supports risk handling is the spiral model. In diagrammatic form, it resembles a spiral with several loops. The spiral's precise number of loops is unclear and varies from project to project. A phase of the software development process is referred to as each spiral loop. The project manager might alter the precise number of phases required to build the product depending on the project's risks. 23 Fig 07: Spiral Model At each given point, the spiral's radius symbolizes the project's overall costs, while its angular dimension indicates how far along the current phase is. 1.3.1.3.1 Steps of the Spiral Model According to the above diagram, the four quadrants represent each phase of the spiral model. The following is a discussion of these four quadrants' functions: 1. Determine the objectives and find potential solutions: At the beginning of each step, the objectives are specified, developed upon, and analyzed while requirements are acquired from the clients. Then, in this quadrant, other solutions that might be possible for the phase are offered. 24 2. Risk identification and resolution: In the second quadrant, all potential solutions are assessed in order to choose the optimal one. The risks connected to that solution are then determined, and the risks are dealt with in the best way feasible. The Prototype is constructed for the ideal outcome at the end of this quadrant. 3. Next-generation product development: when the identified features are developed and tested. The following software version is accessible at the conclusion of the third quadrant. 4. Review and preparation for the next Phase: The customers assess the software's currently created version in the fourth quadrant. Planning for the following step is then begin. 1.3.1.3.2 Advantages of Spiral Model The software life cycle begins with the production of software. The Spiral model is the greatest development model to use since it incorporates risk analysis and risk management at each stage, which is one of its key features. Suitable for large and complex projects. Adaptability in the needs. With this model, needs may be accurately and readily changed at subsequent stages. Additionally, later on, more functionality can be added. It improves client satisfaction. At an early stage of the software development process, we can involve clients in the creation of goods. Additionally, early in the software life cycle, software is developed. It is appropriate for high-risk projects where business requirements could be erratic. This can be used to create a product that is highly customized. 1.3.1.3.3 Disadvantages of Spiral Model Due to its high cost, it is not appropriate for smaller projects. Compared to other SDLC models, it is considerably more complex. Process is intricate. Too much reliance on risk analysis and the need for very specialized knowledge. difficulty managing one's time. Time estimation is highly challenging because the project's starting doesn't know how many phases there will be. 25 1.3.1.4 Differences 1.3.1.4.1 Differences between waterfall model and prototype model Waterfall Model Prototype Model Waterfall Model can be identified as one of Prototype model is developed, tested and the linear and sequential methods process according to customer requirements It highlights the risk analysis Does not give much attention to risk analysis Selecting waterfall model is appropriate If the client is expected to change his when the needs of the customer is clear requirements in the middle of the project it is best to select the Prototype model Association with the user is only taken Hight user involvement place at the beginning It supports automatic code generation, It does not support the automatic minimizing the need for manual code generation of code execution It is complicated to modify the content in The prototype model is easily adaptable waterfall model The complexity of an error grows as the The difficulty of an error is minimal since model's nature evolves; one step follows the prototype allows the developer to the next identify any flaws early in the process 1.3.1.4.2 Differences between Waterfall model and Spiral Model Waterfall Model Spiral Model Simple and not complicated Mode of the Spiral model is more complicated Waterfall model is linear and sequential The spiral model involves an evolutionary method process Risks can be identified after completion of Risks can be identified in the early stage every phases. when using the spiral model 26 Depend on clients Spiral model is acquired by developers Most suitable for small scale projects Most suitable for large scale projects The waterfall model is rather affordable While the spiral model is rather costly It is not difficult to update the content in It is difficult to change the content of the spiral model. waterfall model. In the Waterfall Model, engagement of the Client participation is high in the Spiral client is minimal. Model. The customer has relatively less authority In contrast to the waterfall method, over the administrator customers have influence over the administrator 1.3.1.4.3 Differences between Prototype and Spiral Model Prototype Model A prototype model is a software Spiral Model The spiral model is a risk-driven software development method in which a prototype development method that incorporates is produced, tested, and refined to meet the elements of incremental, waterfall, and demands of the client evolutionary prototyping techniques It's also known as a quick or closed-ended It is also known as a meta model prototype It does not place a high value on risk It requires significant care to analyse risks, assessment and an alternate solution is implemented Client contact is continuing in the prototype model until the final prototype is authorized It is best suited when the client's demand is There is no continuous client engagement in the spiral model unclear and has to be altered are clear It works best when the client's requirements 27 1.3.2 Agile Methodology Agile methodologies in software development are collections of software development strategies that accelerate the development process. In general, agile development-based methodology is a different approach to managing software projects than other traditional software methodologies. Agile methodologies are a collection of software development activities created by experienced software developers. Fig 8: Agile Methodology Agile techniques are progressive, with modest increases. In less than three weeks, the new software product created utilizing agile methodologies is delivered and made available to consumers. These strategies include clients throughout the development process in order to accommodate changing requirements during the process. Agile approaches also reduce documentation by relying on internal conversations rather than formal meetings with written documents. 28 Fig 9: Agile methodology Phases 1.3.2.1 Scrum Methodology Scrum is without a doubt the most popular of the several frameworks that support Agile technique. Scrum is distinguished by development cycles or stages known as sprints, as well as by the maximization of development time for a software product toward a goal known as the Product Goal. This Product Goal is a higher-level value target toward which sprints move the scrum team's product closer. Sprint 1-n Project Inception TO Planning Integration Regression Testing Continuous Integration Transition Development Requirements Refinement Product Backlog Sprint Planning meeting Sprint Backlog Fig 10: Scrum Methodology Sprint Review Meeting Functionally Tested Software 29 In 1995 SCRUM Model was introduced by Ken Swaber as one of the lightweight frameworks and it can be defined as a adaptable, Comprehensive product development strategy in which a development team works together to achieve a common goal. 1.3.2.1.1 Phases of Scrum Methodology Scrum phases refer to the various stages of a Scrum management strategy. They give a framework for an organization and its team members to operate inside when working on a project, as well as tools for assessing and improving the process in the future. Each element of the Scrum process is critical to assisting the organization in maximizing the benefits that this framework delivers. There are five Scrum phases of good project management. 1. Initiation: The initiation phase of a Scrum framework is when you develop a vision for your project. This contains critical identifying points such as noting who the project's stakeholders are and assigning the job of Scrum Master to yourself or another member of the team in charge of carrying out the plan. 2. Planning We intend for a sprint during this phase, which is a brief, time-boxed timeframe that can help the team interact more successfully. As the team completes each sprint, they may subsequently merge them to complete all of the project backlog components. 3. Implementation The sprint is implemented as planned during the implementation phase. They keep an updated backlog throughout this phase, eliminating things when workers finish them and allocating new tasks from the backlog as needed. Consider holding a meeting to deliver project updates and to go through work goals and concerns. Encourage workers to express questions, make suggestions, or submit relevant notes for the other members to hear at this 30 meeting. This procedure, like the planning and estimating phases, can be repeated until the project is completed. 4. Reviewing Consider having a review meeting with the team at the conclusion of the project to discuss the sprint to collect feedback. Based on the findings of the completed sprint, this meeting gives a chance to review what went well and where there are room for growth. It enables the team to make changes to processes and procedures in order to be successful as they go into the next planning and estimate phase. 5. Releasing The last step is the release phase, during which the team delivers any final deliverables to stakeholders, such as releasing a product to market or offering produced technology to a customer. Consider holding a project retrospective meeting with your team after the product has been released to examine the success of each individual sprint and to review the overall performance of the project. Identifying areas that function well and those that struggle will help you choose what to aspire for and what to avoid in future Scrums to get the most out of your next project. 1.3.2.1.2 When to use Scrum Methodology? 1. When the change probability during development is high: Changes in requirements can be a form of common currency in software development, with specialized protocols for managing them. Even if the requirements are well established, there will be occasions when adjustments are necessary as the project advances. This might happen in initiatives when there are technology advancements or in the commercial setting. 2. When the requirements are not explicitly defined: 31 Many times, a customer has a basic notion of the product he wants to create, but he lacks precise or well-defined specifications about how it should be. There are various implications of not having a clear definition of the criteria. 3. When it is necessary to test the solution: This point is closely connected to the preceding ones. An MVP (minimum viable product) may be necessary in the development of a new product in order to test specific market qualities that we may wish to check, allowing it to be iterated based on the results of that test. This process generates some adjustments that have an influence on what has previously been built, as well as new ideas and features to be developed. 4. When the team can manage themselves: Agile working teams demand a particular amount of seniority from their members since, while the Scrum Master is present, the project involves a lot of self-management and communication. The right application of these sorts of approaches may become more complicated if the development team is unskilled. 1.3.2.1.3 Roles and Responsibilities of Scrum Methodology In contrast to traditional project management systems, Scrum does not have and does not require a product manager, task manager, or team leader. A scrum team is slightly different in composition than a standard waterfall project, having three distinct roles such as: Product Owner Scrum Master Development Team These three jobs are coequal, and each has specific duties. 32 Product Owner The role of the Product Owner, who acts as a coordinator between the team and other parties involved, is critical to the success of scrum (stakeholders). Product owners are not in charge of the program's status. A product owner is not the same as a project manager. They guarantee that the development team adds the maximum value to the organization. It is also critical that the product owner be an individual. No development team wants contradictory advice from different product owners. Furthermore, having numerous product owners may cause confusion for both the team and the stakeholders, resulting in sprint cycle delays. In scrum-enabled organizations, the tasks and responsibilities of each Product Owner are never the same. The Product Owner's job is the most complex in terms of the method being followed. Product owners are the product's advocates. They are focused on understanding the business and market needs and then prioritizing the work to be done by the engineering team accordingly. Qualities of Good Product Owners Give the team specific instructions on which features to deploy next The priority of each item in the Product Backlog is set Create and maintain the product backlog Work closely with the business and the team to ensure that everyone knows the work items in the product backlog. In addition, the Product Owner is accountable for the return on investment (ROI). After all, it is his responsibility to manage the financial aspects of product development, which he accomplishes by consistent effort and prioritization of increasing tasks. What does it mean to be a Product Owner? Liable for the achievement of the team's product delivery result User stories are prepared for the growth of the team 33 Domain Knowledge is a must Respond quickly to callbacks Interact with all stakeholders, funders, and team members. Taking excellent care of the project's finances. Scrum Master Fig 11: Scrum Master Scrum masters are the scrum champions of their team. The Scrum Master is the specific person in charge of ensuring that Scrum values, principles, and rules are implemented and enforced. They train the team, the product owner, and the company on the scrum process and search for methods to improve its implementation. An efficient scrum master knows the team's work and may assist the team in optimizing their delivery flow. As the primary facilitator, they organize the necessary resources (both human and logistical) for sprint planning, stand-up, sprint review, and other agile procedures. Scrum masters help investigate and resolve barriers and distractions for the development team. They shield the development team from outside interruptions wherever feasible. Another key role of the Scrum master is to ensure that the team follows the rules and fully understands the Scrum technique. 34 Development Team A Development Team is a group of people that collaborate to create and deliver the needed and committed product increments. It is made up of cross-functional people who are capable of meeting the sprint objectives. This might comprise software engineers, architects, programmers, analysts, system administrators, quality assurance specialists, testers, UI designers, and so on. The Development Team creates the product that the Product Owner specifies, such as an application or website. Scrum teams are "cross-functional." Each Sprint, the Development Team contains all of the skills required to develop a potentially shippable product. The Development Team self-organizes and has a high level of autonomy and responsibility. Fig 12: Development Team 35 1.3.2.1.4 Advantages of Scrum Methodology Adaptable and Flexible - It promotes innovative techniques - Creativity is fostered and new ideas are likely to emerge when Scrum teams collaborate and analyse ideas from all of its members. It frequently results in higher-quality work - Having everyone on the team accept full accountability and ownership of their job helps foster a productive environment that results in high-quality outcomes. - Adopting the Scrum model may save a company money since it involves less paperwork and management. It is inexpensive Customer satisfaction rises as a result - Scrum is appropriate for a wide range of locations and circumstances that do not have well defined criteria at the outset and necessitate a flexible approach. Everyone on the team working to the best of their ability and continually changing depending on internal and external input can result in customer-friendly goods and solutions. It usually leads in job satisfaction - With everyone on the team assuming full responsibility for their work, the Scrum methodology increases the likelihood that project participants will be engaged and happy. 36 1.3.2.1.5 Disadvantages of Scrum Methodology But, like every other methodology, scrum has its drawbacks. Nothing is perfect, even the Scrum approach. Scrum is sometimes paired with other project management strategies to help lessen some of these drawbacks: Due of the lack of a fixed end-date, Scrum frequently leads to scope creep If they aren't dedicated or cooperative, there's a good probability the project will fail Implementing the Scrum framework in large groups is difficult Only experienced team members can ensure the framework's success Team members might become irritated by daily meetings Any team member who departs in the middle of a project might have a significant negative influence on the project Quality is difficult to implement until the team goes through a rigorous testing procedure 37 1.3.2.2 XP (Extreme Programming) Extreme Programming (XP) is an agile software development approach that attempts to deliver higher quality software while also improving the development team's quality of life. In terms of proper engineering methods for software development, XP is the most detailed of the agile frameworks. Fig 13: Extreme Programming (XP) 1.3.2.2.1 Steps of the XP 1. Planning The first step involves the client meeting with the development team and presenting the requirements in the form of user stories to explain the intended outcome. The team then estimates the stories and develops a release strategy that breaks down the required functionality 38 into iterations. If one or more of the tales cannot be approximated, so-called spikes are inserted, indicating that additional investigation is required. 2. Designing Designing is a component of the planning process, although it can be separated to emphasize its significance. It's connected to one of the primary XP values we'll go over later - simplicity. A smart design gives the system meaning and structure while avoiding unneeded complications and redundancies. 3. Coding Coding is the phase in which real code is written using XP principles like as coding standards, pair programming, team collaboration, and collaborative code ownership. 4. Testing Extreme programming revolves around testing. It is a routine activity that includes both unit tests (automated testing to ensure that the generated feature functions properly) and acceptance tests (customer testing to verify that the overall system is created according to the initial requirements). 5. Listening Regular connection and feedback are essential components of listening. Clients and project managers are essential in describing the intended business rationale and value. 1.3.2.1.2 When we can apply Extreme Programming? When software needs that are always changing When risks associated with fixed-time projects utilizing new technologies When extended development team that is small and co-located The technology used enables automated unit and operational testing 39 1.3.2.1.3 Advantages and Disadvantages of Extreme Programming Extreme programming has accelerated software development, but it is not appropriate for every case or team. At the start of the project, XP considers that the client does not have a clear vision of the end result. In certain instances, the software can be agile, which means it can be designed and built progressively. Advantages Interpersonal relationship with the client Disadvantages Additional effort should be given There will be no additional programming The customer must be involved in the labour. process. Continuous testing results in stable software. Considerable time investment Pair programming helps to avoid errors. Costs are rather expensive. There will be no overtime; teams will Version control is required. proceed at their own rate. Changes may be implemented quickly. Practice necessitates self-discipline. 1.3.2.3 Advantages of Agile Methodology Satisfy the client by delivering valuable software on time and on a consistent basis. The emphasis is on customer satisfaction and high-quality deliveries Accept changing needs, especially if they emerge late in the development process. Agile methods use change for the benefit of the customer's competitive advantage. Instead of fighting change, learn to embrace it Deliver functioning software on a regular basis, from a few weeks to a few months, with a preference for the shorter duration. Continuously provide outcomes throughout a project, not just at the end Throughout the project, businesspeople and developers must collaborate on a regular basis. Collaboration is essential 40 Build initiatives around motivated people. Give them the atmosphere and support they require, and trust them to do the task. Bring on talented and industrious team members and get out of their way Face-to-face communication is the most efficient and effective way of transmitting information to and within a development team. Reduce the number of potential for misinterpretation as much as feasible 1.3.2.4 Disadvantages of Agile Methodology It is less predictable The Agile method's inherent flexibility also implies a far lower degree of predictability. Accurately estimating the time required or quantifying the resources and efforts required to execute a project can be significantly more challenging. Many teams are afraid of ambiguity, which may lead to dissatisfaction and poor decision-making. More time and effort Communication and collaboration are good, but they require more time and energy from everyone involved. Greater expectations of developers and clients Agile Methodology requires commitment from all parties involved in order to be effective. Anyone who is not on board can have a detrimental influence on the project's quality. There is a lack of relevant documents Because tasks are frequently finished only in time for progress under the Agile Method, documentation is generally less extensive, which might lead to confusion and challenges later on. 41 Projects can quickly get off track Because Agile Methodology is less regimented, projects can readily deviate from their initial scope. 2.1 What is Feasibility Study? A feasibility study, as the name implies, is intended to determine if a project or proposal is viable. It is an evaluation of the feasibility of a given project or plan. A feasibility study is a component of any project's or plan's early design stage. It is carried out in order to discover the strengths and weaknesses of a prospective project or an existing firm objectively. It may aid in identifying and assessing the natural environment's potential and risks, as well as the resources needed for the project and its chances of success. It is carried out in order to answer the following questions: Is the firm equipped with the necessary resources and technology? Will the corporation get a good enough return on its investment? 2.2 Importance of using feasibility study Uncertainty is a reality that all businesses encounter on a daily basis. Getting clients in the door, encouraging them to spend, and eventually turning a profit are fundamental goals that might be tough to execute at times. Changing, adapting, and introducing new goods and ideas into your company mix are methods to reduce some of the uncertainties you encounter, but such processes may be exceedingly unpredictable without sufficient preparation and planning. Enter the feasibility study: an opportunity to ask and receive answers to questions that will help you assess potential and predict success or failure. Most Likely to Succeed 42 The phrase "feasible" refers to an action or occurrence that is likely, likely, or viable to occur or occur. A feasibility study is the sum of the actions you perform and the questions you ask to establish the viability of an idea, theory, or strategy. Effective research can help to decide whether to proceed with the concept, tweak it, or trash it entirely and start again. Specific and focused Feasibility studies are specific and targeted. They begin with a single question - if the concept, event, or action is a feasible solution - and require you to focus entirely on that subject, digging down to investigate alternative possibilities. The Entire Picture Feasibility studies are significant because they force employees to think about the large picture first, then think top-down. In this manner, one or two generic beginning questions lead to a slew of subsequent, more comprehensive inquiries that narrow in focus as you approach closer to an eventual response. Alternative Possibilities and Solutions Feasibility studies provide the opportunity to "get it right" before devoting time, money, and corporate resources to a concept that may not function as expected, necessitating more investment to repair flaws, eliminate limits, and then simply try again. Feasibility studies may also introduce you to fresh options, opportunities, and solutions that you may not have explored otherwise. There are no right or incorrect answers to your inquiries, but a response that you don't necessarily want or expect might open up new profit opportunities. 2.3 Elements of Feasibility Study A business case study for a project is an important stage in the project lifecycle since it depicts the foundation of the project's inception. In most corporate organizations, the completion of a business case is the first step toward project start. Any good feasibility study for a business case consists of six sections. They are, 43 1. The Project Scope: The project scope defines the business problem or opportunity that will be handled. The scope should be clear and to the point, and it is also vital to describe aspects of the company that are directly or indirectly affected by the project, such as project participants and end-user regions. 2. The Current Analysis: The current analysis is used to define and comprehend the current way of implementation, which might be a system, a product, or something else. The existing approach's strengths and drawbacks should also be acknowledged. 3. Requirements: The technique by which the requirements are defined is determined by the project's focus. 4. The Approach: The approach describes the suggested solution or plan of action to meet the requirements. Various possibilities are examined here, along with an explanation of why the preferred approach was chosen. 5. Evaluation: Examine the cost-effectiveness of the chosen technique. This begins with an analysis of the project's expected overall cost. Other options are estimated in addition to the recommended solution in order to provide an economic comparison. 6. Review: that all of the preceding parts are then gathered into a feasibility study and a formal review is undertaken with all stakeholders concerned. The evaluation serves two purposes: to prove the depth and correctness of the feasibility study, and to make a project selection. 2.4 Types of Feasibility Study Criteria There are several categories of feasibility studies, each of which has a distinct amount of influence on a project. Some of them are, 44 Technical Operational Economic Schedule Cultural Legal/Ethical Technical Feasibility The feasibility study examines if the existing technical resources are sufficient for the project and whether the available technical resources are capable of implementing the planned system. This assesses the available technical resources and their skills in relation to the technical needs of the proposed project. This comprises the hardware, software, and other technical requirements of the proposed system. Operational Feasibility This is a measure of how effectively a suggested solution addresses the client's problems or how well the project can satisfy the needs of the company. This also includes an examination of how a project plan fits the criteria provided during the system development requirements analysis phase. Economic Feasibility Economic feasibility examines if the needed software can generate financial rewards for a company. It includes the cost of the software development team, the expected cost of hardware and software, the cost of conducting a feasibility study, and so on. Furthermore, the benefits that may be obtained by designing the program must be considered. Software is considered to be economically viable if it focuses on the following challenges. The expense of developing software to provide long-term benefits for a company cost of performing a complete software investigation Hardware, software, development team, and training costs 45 Schedule Feasibility the process of determining how well the projected time frame and completion dates for all main activities in a project satisfy organizational deadlines and restrictions for effecting change. Cultural Feasibility The cultural viability of the proposed project includes its compatibility with the project's cultural surroundings. In labour-intensive projects, planned activities should be blended with local cultural beliefs and customs. what effect will it have on both local and global civilization? environmental consequences does the feasibility study have? Legal/Ethical Feasibility The project team must do a detailed examination of the legal concerns surrounding the project on several levels. A thorough legal due diligence should be performed to guarantee that all expected legal needs, which have not or will not be addressed in earlier assessment procedures, are satisfied for the project's progress. 46 2.5 Advantages and Disadvantages of Feasibility Study Advantages Disadvantages It enables stakeholders to quickly recognize Since this study was conducted by gathering the benefits and drawbacks of the proposed information rather than addressing a realproject. world scenario, the feasibility results may result in poor decision making. Feasibility studies give investors useful This is a time-consuming and expensive information that can help them make sound process. business decisions. A feasibility study can identification of project aid in hazards the It may take some time and effort to conduct and an analysis. associated contingency plans. Feasibility studies also assist corporations in the establishment of new businesses, such as identifying how the business will work, potential barriers, competition, market analysis, and the amount and source of capital required to build the business. Considering the legal structure of the company. 2.6 Desirability, Viability and Feasibility of the System 2.6.1 Desirability: Customers or consumers desire or require products that match the attractiveness requirements. After all, if you don't create a product that people want to purchase, you won't make any money. To ensure your product's appeal, it must address an issue for someone in an intuitive and pleasing manner. 47 2.6.2 Viability: Products that satisfy the viability requirements make good commercial sense. These are goods that, both immediately after their release and over time, will bring in money or save money for a business. A product's viability must be assessed by corporations by looking at: who will be prepared to purchase the project? if the sum equals profitability how they intend to pay for it 2.6.3 Feasibility: A product must be feasible in order to be constructed, either by the firm that developed it or by a third party with the necessary technical skills. A corporation must be confident in the ability to create the technology required to manufacture the product for it to be viable. They must also have faith that it can be accomplished in a fair amount of time and at a cost that will keep the product in demand. Feasibility doesn't just consider if a technology can be used in practice. It also relies on whether the product can be disseminated in a way that will guarantee it reaches the correct clients, whether additional team members are required to produce the product, and whether the new technology might help the company's existing goods. 2.7 Investigation Techniques The following are the primary techniques employed to conduct system investigations: o o o o Investigations Interviews Document Analysis Observations 48 Investigations During an inquiry, data is acquired using a professionally constructed questionnaire. After a brainstorming session and after considering the goal of the preliminary survey, the questionnaire is created. Interviews To obtain information directly from the users of the system under study, interviewing is a face-to-face approach. To get information from the interviewee that would be helpful, the interviewer will ask them a few pointed questions. Document Analysis The document analysis approach entails looking at the data, records, documentations, and procedure manuals that are currently in use for the system. Using this technique, the analyst may get accurate and realistic information on the system. Observations This approach entails watching how processes are carried out. The analyst uses the current system to examine how work is done and how procedures are followed. This allows the analyst to see first-hand how the job is actually done and what it entails. 2.8 Feasibility Report Automated Project Management System for E-solutions private limited Introduction: This feasibility study assessed E-solutions Private Limited's ability to execute the proposed Automated Information Management System. Details of the Project: Budget - LKR 1,000,000.00 49 Schedule Duration - 5 months Technical Feasibility Users would be able to access the proposed online application using widely used web browsers as Google Chrome, Microsoft Edge, Firefox, etc. Local servers will be used to host the application on-site. The connection is sufficient thanks to the current LAN infrastructure. Internet access won't be allowed for the system. The development team have all the technical skills necessary to put the system into operation. Infrastructure The program cannot be hosted on the currently available hardware, hence new server environments are needed for the web server and the database server. Operational Feasibility: When the proposed system is deployed, personnel should get appropriate system training that satisfies all of E-solutions private Limited's workflow criteria. Legal Feasibility: According to each client agreement, the system has the capacity to store project-related data from E-solutions private Limited. Economic Feasibility: Evaluation of the cost elements as follows Cost Item Value (LKR) Development Cost 600,000 Software Cost 150,000 Hardware Cost 420,000 Miscellaneous Cost 100,000 50 Total 1,270,000 3.1 Functional Requirements: Functional requirements are descriptions of needed product characteristics or capacities of a proposed system. These criteria indicate system-provided user amenities. Functional requirements explain the behaviour of a system under certain situations. Eg: E-solutions Private Limited's Project Director would want to start a project in the system. Both the development team and the stakeholders must have a clear and detailed understanding of the functional requirements; otherwise, the final system may not fulfil the expectations of the customer. A system's functional requirements should include the following elements: Details of procedures performed on each screen Details of procedures performed on each screen It must include descriptions of system reports and other outputs Comprehensive information on the system's processes It should specify who is authorized to create/modify/delete data in the system The functional document should provide information on how the system will meet applicable regulatory and compliance requirements. 3.2 Non-functional Requirements Non-functional Requirements define a software system's quality attributes. They evaluate the software system based on its responsiveness, usability, security, portability, and other non-functional characteristics that are crucial to its success. Eg: Each web page has to load in less than 3 seconds 51 Non-functional requirements for the new system might be thought of as constraints, objectives, or control mechanisms. They specify how well or to what standard the planned system should function. A certain system, for example, should be able to execute 120 transactions per minute. Therefore, at the system analysis stage, it is critical to pay close attention to non-functional needs as well as functional requirements. 3.3 Assessment of the effectiveness and suitability of the agile methodology in relation to the proposed system Product Quality Agile methodology improves product quality in software development through, At the end of each sprint, do a retrospective to focus on ongoing improvement Defining and developing requirements in a timely way so that product knowledge is as relevant as possible Embracing technical brilliance, improved design, and strategies for sustainable development Product increases are continuously integrated and tested Maintaining improved team communication Use automated testing tools during the day, test overnight, and debug in the morning At the end of each sprint, there is continuous customer involvement and product demonstration to the client It is simple to fix problems and flaws due to concurrent development and testing Having a product owner who is knowledgeable about the product's specifications and the demands of the consumer Motivated Team An agile team is a self-organizing, cross-functional group. Being a member of a selfgoverning team encourages people to become creative, inventive, and to support the 52 development of multidisciplinary abilities. A scrum master protects the team from outside influences and obstructions. Agile approach encourages team members to work effectively together and to communicate with one another as well as with the product owner and clients. Enhanced Performance Visibility In an Agile environment, every member of the team has the ability to gain an understanding of how things are progressing on the project at any given time. The Project status is visible thanks to daily scrums, progress charts, and visual boards. Agile Team Structure The number of team members in an agile team is restricted. It is a cross-functional team, and they have all of the competences required to do their task without relying on those who are not members of the team. Improved Predictability To increase project predictability, Agile methodology incorporates various best practices, artifacts, and tools, which include, Time-boxed sprints of equal duration throughout the project lifetime provide an estimate of cost each sprint The agile team velocity enables the project team to set release timelines and budgets, as well as the remaining product backlog The project team may assess the performance of each sprint by using information from daily scrum meetings, sprint burn down charts, and task boards Reduced Project Risk Agile methodology minimizes project risk by, 53 Sprint development ensures a short period between initial project investment and either falling quickly or understanding that a product or method will succeed Having a functional product from the very first sprint ensures that no agile project fails altogether Developing requirements to the definition of worn out for each sprint so that project sponsors have finished, useable features regardless of what happens with the project in the future Self-funding initiatives generate money early, allowing groups to take control of a project with minimum initial investment 4.1 System Design The process of specifying technical characteristics of a proposed software system, such as modules, system architecture, components, user interfaces, integration points, database specification, and other essential technical concerns, is known as systems design. 4.2 Design Specification Document The design specification document includes detailed descriptions of the software that will be built, such as the proposed system's architecture, components to be implemented, database design, suggested system interfaces, and so on. A senior technical member of the project team, such as a software architect or technical lead, generally writes the design specification. This document is regarded as the project team's primary technical reference source throughout the project's life cycle. The software design document aids in ensuring that the program's design specifications are properly understood and clear to the project team. 54 E-Solutions Private Limited Software Design Specification for an Automated Project Detail Management System 1. Introduction This paper details the Automated Project Detail Management System's Detailed Technical Design, which includes system architecture sub-systems, components and their related interfaces, database schemas, design goals, and the reasoning for the selected design. This paper includes both high-level and low-level designs. This paper should be read by someone who has expertise with data flow diagrams, control flow diagrams, interface designs, and technical requirements. 2. Design Considerations Meet the customer-defined system performance targets Make a user-friendly, robust application Provide a dependable and expandable system Meet the customer-defined system security objectives 3. Architecture Design Architectural Design gives an overall perspective of the system, including its subsystems, which are produced from the requirement model's analytical packages. Software development initiatives aiming for quick, sustainable delivery are merging agile and architectural approaches to balance opposing goals of short-term speed and long-term stability. 55 Architecture Diagram Requirements Reports Deliverables Strategic Planning and Control Status Reports Outline Plan Work Directives Work Schedule Monitoring Detailed Planning and Scheduling Technical Development Configuration Management Deliverables Development Reports Unchecked Deliverables Quality Control 56 Component Diagram The component diagram depicts the structural links and interactions between the components. Project Specification (Project Overview) Accounting & Cost (Manage the project cost) Administration & Security (set up and manage new projects & users) Visualization tool (Visualize the project cost, resources & status) Project Cost Project Status Content management (manage the project content) Collaboration Documents Process Management (manage the project process) Work flow management Meeting notes Resource Management (manage the project resources) task status report Project members services task & scheduling equipment 57 Interface Specification Form for login: LOGIN User Name: Password: Login Save Login Info Main Menu: Project Project Member Project Category Project Manager Project Member Assignment 58 Project form: Project Project Company Category Project Name Start Date End Date Remarks PROJECT MEMBER Member ID Member Name Member No. E-mail Member No. Password Status Add Update Delete 59 Justification of using agile methodology in the context of the business problem System design approach The system was designed using the Agile Design process. Agile employs an iterative design approach that begins with the first stage and progresses to the final level. The result is then analysed, and several iterations are performed to further enhance it. The steps of the agile design process happen concurrently. You start by breaking down the functionality into little bits that can be supplied individually and working on them. This allows for speedier design and faster feedback on work. The agile design method includes the following characteristics: Quick Responses: It is simpler to know what the consumer wants sooner rather than supplying him with a complete prototype and then asking for feedback. Change Management: Design changes are becoming easier and less expensive. There is no squandering of time or money. Quick Development: Providing tiny bits of design to the development team allows for faster implementation. The development team does not wait for the design to be completed before beginning implementation. The Agile Analysis Method was utilized to create the Automated Project Management System at E-solutions Private Limited for the reasons stated above. 60 Grading Criteria Achieved Feedback LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis methodologies. P1 Discuss the strengths and weaknesses of the traditional and agile systems analysis methodologies. M1 Compare and contrast the strengths and weaknesses of the traditional and agile systems analysis methodologies. LO2 Produce a feasibility study for a system for a business-related problem. P2 Produce a feasibility study for a system for a business related problem. 61 M2 Evaluate the relevance of the feasibility criteria on the systems investigation for the business related problem. LO1 & LO2 D1 Critically evaluate the strengths and weaknesses of the traditional and agile methodologies and feasibility study. LO3 Analyse their system using a suitable Methodology P3 Review a system using a suitable methodology for a business-related problem. M3 Analyse the effectiveness of the methodology used in providing a solution for a given business context. LO4 Design the system to meet user and system Requirements 62 P4 Design a fully functional system to meet user and system requirements for the business related problem. M4 Assess the effectiveness of the system design with reference to the methodology used and how the design meets user and system requirements. LO3 & LO4 D2 Justify the choice of the analysis methodology used in the context of the business problem. 63 64 1. System Analysis and Design 1.1 What is a System? The word "system" comes from the Greek word "systema," which denotes a structured interaction between any group of components working toward a single goal or purpose. A system must adhere to three fundamental restrictions. 2. A system needs to have some kind of structure and behavior that is planned to accomplish a specific goal 3. The system's component parts must be interdependent and interconnected 4. The organization's goals are more important than the goals of its subsystems 1.2 Systems Analysis 65