Software Development Lifecycles: Waterfall and Rapid Application Development (RAD), Study Guides, Projects, Research of Assembly Language Programming

Download Software Development Lifecycles: Waterfall and Rapid Application Development (RAD) and more Study Guides, Projects, Research Assembly Language Programming in PDF only on Docsity! Assignment Brief 01 (RQF) Higher National Certificate/Diploma in Business Student Name/ID Number: VO NGUYEN DUY NAM / GCS200888 Unit Number and Title: Unit 09: Software Development Life Cycle Academic Year: Unit Assessor: Assignment Title: Plan a software development life cycle Issue Date: Submission Date: Internal Verifier Name: Date: Submission Format: Format: ● The submission is in the form of 1 document. ● You must use the Times font with 12pt size, turn on page numbering; set line spacing to 1.3 and margins to be as follows: left = 1.25cm, right = 1cm, top = 1cm, bottom = 1cm. Citation and references must follow the Harvard referencing style. Submission: ● Students are compulsory to submit the assignment in due date and in a way requested by the Tutor. ● The form of submission will be a soft copy posted on http://cms.greenwich.edu.vn/. ● Remember to convert the word file into PDF file before the submission on CMS. Note: 1 ● The individual Assignment must be your own work, and not copied by or from another student. ● If you use ideas, quotes or data (such as diagrams) from books, journals or other sources, you must reference your sources, using the Harvard style. ● Make sure that you understand and follow the guidelines to avoid plagiarism. Failure to comply this requirement will result in a failed assignment. Unit Learning Outcomes: LO1 Describe different software development lifecycles. LO2 Explain the importance of a feasibility study. Assignment Brief and Guidance: Assignment scenario Tune Source is a company headquartered in southern California. Tune Source is the brainchild of three entrepreneurs with ties to the music industry: John Margolis, Megan Taylor, and Phil Cooper. Originally, John and Phil partnered to open a number of brick-and-mortar stores in southern California specialising in hard-to-find and classic jazz, rock, country, and folk recordings. Megan soon was invited to join the partnership because of her contacts and knowledge of classical music. Tune Source quickly became known as the place to go to find rare audio recordings. Annual sales last year were $40 million with annual growth at about 3%–5% per year. Tune Source currently has a website that enables customers to search for and purchase CDs. This site was initially developed by an Internet consulting firm and is hosted by a prominent local Internet Service Provider (ISP) in Los Angeles. The IT department at Tune Source has become experienced with Internet technology as it has worked with the ISP to maintain the site. System Request Project Sponsor: Carly Edwards, Assistant Vice President, Marketing. Business Need: This project has been initiated to increase sales by creating the capability of selling digital music downloads to customers through kiosks in our stores, and over the Internet using our website. Business Requirements: Using the Web or in-store kiosks, customers will be able to search for and purchase digital music downloads. The specific functionality that the system should have includes the following: ● Search for music in our digital music archive. ● Listen to music samples. 2 4. Assess the impact of each feasibility criterion on a software investigation. Discussion and represent as feasibility alternatives matrix for Tune Source project ● Word limit: 500 – 700 words. 5 Learning Outcomes and Assessment Criteria (Assignment 01): Learning Outcome Pass Merit Distinction LO1 Describe different software development lifecycles P1 Describe two iterative and two sequential software lifecycle models. P2 Explain how risk is managed in the Spiral lifecycle model. M1 Describe, with an example, why a particular lifecycle model is selected for a development environment. D1 Assess the merits of applying the Waterfall lifecycle model to a large software development project. LO2 Explain the importance of a feasibility study P3 Explain the purpose of a feasibility report. P4 Describe how technical solutions can be compared. M2 Discuss the components of a feasibility report. D2 Assess the impact of different feasibility criteria on a software investigation. 6 TABLE OF CONTENTS: P1. Describe two iterative and two sequential software lifecycle models................................................... 6 1. Waterfall Model: ..................................................................................................................................... 6 2. V-Model: ................................................................................................................................................. 8 Business Requirement Analysis ...................................................................................................................9 System Design .........................................................................................................................................….9 Architectural Design .....................................................................................................................................9 Module Design.......................................................................................................................................…...9 Coding Phase............................................................................................................................................….9 Validation Phases ....................................................................................................................................….9 Unit Testing..............................................................................................................................................….9 Integration Testing ......................................................................................................................................10 System Testing.............................................................................................................................................10 Acceptance Testing......................................................................................................................................10 3. Spiral Model:...........................................................................................................................................11 4. Rapid development:....................................................................................................................................13 P2. Explain how risk is managed in the Sprial lifecycle model.................................................................16 M1. Describe, with an example, why a particular lifecycle model is selected for a development environment………………………………………………………………………………………………18 P3. Explain the prupose of a feasibility report............................................................................................23 A feasibility report consits of: ...............................................................................................................….23 Purpose of feasibility study:........................................................................................................................23 M2. Discuss the components of a feasibility report. ..................................................................................25 Criteria/Constraints: ...................................................................................................................................26 Method: ......................................................................................................................................................27 P4. Describe how technical solutions can be compared. ...........................................................................30 The process of technical solutions:.............................................................................................................30 There are many factors in Technical Solutions that we need have to measure detaily:.............................31 Sync: ..........................................................................................................................................................32 References:.................................................................................................................................................34 7 - Under the V-Model, the corresponding testing phase of the development phase is planned in parallel. So, there are Verification phases on one side of the ‘V’ and Validation phases on the other side. The Coding Phase joins the two sides of the V-Model. - The following illustration depicts the different phases in a V-Model of the SDLC. There are several Verification phases in the V-Model, each of these are explained in detail below: - Business Requirement Analysis: This is the first phase in the development cycle where the product requirements are understood from the customer’s perspective. This phase involves detailed communication with the customer to understand his expectations and exact requirement. This is a very important activity and needs to be managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing. - System Design: Once you have the clear and detailed product requirements, it is time to design the complete system. The system design will have the understanding and detailing the complete hardware and communication setup for the product under development. The system test plan is developed based on the system design. Doing this at an earlier stage leaves more time for the actual test execution later. - Architectural Design: Architectural specifications are understood and designed in this phase. Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. The system design is broken down further into modules taking up different functionality. This is also referred to as High Level Design (HLD). The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. With this information, integration tests can be designed and documented during this stage. - Module Design: In this phase, the detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). It is important that the design is compatible with the other modules in the system architecture and the other external systems. The unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage. These unit tests can be designed at this stage based on the internal module designs. 10 - Coding Phase: The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best suitable programming language is decided based on the system and architectural requirements. The coding is performed based on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository. - Validation Phases: The different Validation Phases in a V-Model are explained in detail below. - Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing. - Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are performed to test the coexistence and communication of the internal modules within the system. - System Testing: System testing is directly associated with the system design phase. System tests check the entire system functionality and the communication of the system under development with external systems. Most of the software and hardware compatibility issues can be uncovered during this system test execution. - Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems available in the user environment. It also discovers the non-functional issues such as load and performance defects in the actual user environment. 3. The usage for V-Model: V- Model application is almost the same as the waterfall model, as both the models are of sequential type. Requirements have to be very clear before the project starts, because it is usually expensive to go back and make changes. This model is used in the medical development field, as it is strictly a disciplined domain. The following pointers are some of the most suitable scenarios to use the V-Model application. • Requirements are well defined, clearly documented and fixed. • Product definition is stable. • Technology is not dynamic and is well understood by the project team. • There are no ambiguous or undefined requirements. • The project is short. Pros and Cos of V-Model: 11 4. Rapid development: - Rapid Application Development (RAD) is a form of agile software development methodology that prioritizes rapid prototype releases and iterations. Unlike the Waterfall method, RAD emphasizes the use of software and user feedback over strict planning and requirements recording. - There are 5 essential stages or phases in RAD: Stage 1: Business Modeling: Business modeling step in the RAD model takes information from the company gathered through many business-related sources. This info is then combined into a useful description of how the data can be used when it is processed, and what is making this specific information successful for the industry. Stage 2: Data Modeling: During the Data Modeling stage, all the information gathered during the Business Modeling phase is analyzed. Through the analysis, the information is grouped into different groups that can be useful to the company. The quality of each data group is carefully examined and given an accurate description. A relationship between these groups and their usefulness as defined in the Business Modeling step is also established during this phase of the RAD model. Stage 3: Process Modeling: The Process Modeling phase is the step in the RAD model procedure where all the groups of information gathered during the Data Modeling step are converted into the required usable information. During the Process Modeling stage, changes and optimizations can be done, and the sets of data can be further defined. Any descriptions for adding, removing, or changing the data objects are also created during this phase. Stage 4: Application Generation: The Application Generation step is when all the information gathered is coded, and the system that is going to be used to create the prototype is built. The data models created are turned into actual prototypes that can be tested in the next step. Stage 5: Testing and Turnover : The Testing and Turnover stage allows for reduced time in the overall testing of the prototypes created. Every model is tested separately to identify and adapt the components quickly to create the most effective product. Since most of the elements have already been examined previously, there should not be any major problems with your prototype. The usage of RAD model: - RAD models can be very successful when a quick delivery of a product is needed for a customer. It is also the best model to choose when there are going to be changes made to the prototype throughout the process before the final product is completed. It is important to know that the RAD model is only valid when there are plenty of knowledgeable developers and engineers on hand prepared to work on the progress of the product. The customer must also remain committed to the process and the schedule in place for the completion of the model. When either of these two components is not available, the RAD formula can fail. 12 M1. DESCRIBE, WITH AN EXAMPLE, WHY A PARTICULAR LIFECYCLE MODEL IS SELECTED FOR A DEVELOPMENT ENVIRONMENT. - The Software Development Life Cycle concept can be applied to technical and non-technical project management. Any method included in SDLC typically involves project managers and program managers together with software engineers, developers, and end-users. Every hardware or software system goes through an iterative development process with various steps. There are key Software Development Life Cycle stages that constitute a rigid structure of system development. Any software engineer should have enough knowledge on how to choose the appropriate SDLC methodology based on the project context and business requirements. - Selection of appropriate life cycle model for a project: Selection of proper lifecycle model to complete a project is the most important task. It can be selected by keeping the advantages and disadvantages of various models in mind. The different issues that are analyzed before selecting a suitable life cycle model are given below : - Characteristics of the software to be developed: The choice of the life cycle model largely depends on the type of the software that is being developed. For small services projects, the agile model is favored. On the other hand, for product and embedded development, the Iterative Waterfall model can be preferred. The evolutionary model is suitable to develop an object-oriented project. User interface part of the project is mainly developed through prototyping model. - Characteristics of the development team: Team member’s skill level is an important factor to deciding the life cycle model to use. If the development team is experienced in developing similar software, then even an embedded software can be developed using the Iterative Waterfall model. If the development team is entirely novice, then even a simple data processing application may require a prototyping model. - Risk associated with the project: If the risks are few and can be anticipated at the start of the project, then prototyping model is useful. If the risks are difficult to determine at the beginning of the project but are likely to increase as the development proceeds, then the spiral model is the best model to use. - Characteristics of the customer: If the customer is not quite familiar with computers, then the requirements are likely to change frequently as it would be difficult to form complete, consistent and unambiguous requirements. Thus, a prototyping model may be necessary to reduce later change requests from the customers. Initially, the customer’s confidence is high on the development team. During the lengthy development process, customer confidence normally drops off as no working software is yet visible. So, the evolutionary model is useful as the customer can experience a partially working software much earlier than whole complete software. Another advantage of the evolutionary model is that it reduces the customer’s trauma of getting used to an entirely new system. - Agile Model: The Agile model was designed to incorporate change requests quickly. In this model, requirements are decomposed into small parts that can be incrementally developed. But the main principle of the Agile model is to deliver an increment to the customer after each Timebox. The end date of an iteration is fixed, it can’t be extended. This agility is achieved by removing unnecessary activities that waste time and effort. - Example: Adobe is working on project to come up with a competing product for Microsoft Word, that provides all the features provided by Microsoft Word and any other features requested by the marketing team. The final product needs to be ready in 10 months of time. Let us see how this project is executed in traditional and Agile methodologies. In traditional Waterfall model • At a high level, the project teams would spend 15% of their time on gathering requirements and analysis (1.5 months) 15 • 20% of their time on design (2 months) • 40% on coding (4 months) and unit testing • 20% on System and Integration testing (2 months). • At the end of this cycle, the project may also have 2 weeks of User Acceptance testing by marketing teams. • In this approach, the customer does not get to see the end product until the end of the project, when it becomes too late to make significant changes. The image below shows how these activities align with the project schedule in traditional software development. - With Agile development methodology • In the Agile methodology, each project is broken up into several ‘Iterations’. • All Iterations should be of the same time duration (between 2 to 8 weeks). • At the end of each iteration, a working product should be delivered. • In simple terms, in the Agile approach the project will be broken up into 10 releases (assuming each iteration is set to last 4 weeks). • Rather than spending 1.5 months on requirements gathering, in Agile software development, the team will decide the basic core features that are required in the product and decide which of these features can be developed in the first iteration. • Any remaining features that cannot be delivered in the first iteration will be taken up in the next iteration or subsequent iterations, based on priority. • At the end of the first iterations, the team will deliver a working software with the features that were finalized for that iteration. • There will be 10 iterations and at the end of each iteration the customer is delivered a working software that is incrementally enhanced and updated with the features that were shortlisted for that iteration. The iteration cycle of an Agile project is shown in the image below: 16 - This approach allows the customer to interact and work with functioning software at the end of each iteration and provide feedback on it. This approach allows teams to take up changes more easily and make course corrections if needed. In the Agile approach, software is developed and released incrementally in the iterations. An example of how software may evolve through iterations is shown in the image below. 17 Does it explain the way you obtained the facts and ideas presented in the report?✓ Does it persuade the readers that this method would produce reliable results? ✓ • Overview of Alternative Options – You must underline the key features of each possible option. Make sure they are easy to understand and presented in a friendly layout. Keep in mind that the goal is to allow your audience to make the best decision. Does it present a general description of each alternative? ✓ • Evaluation – This should be the bulk of your report, you must evaluate the options using the criteria you created. Add graphs, charts, etc. to show that you have studied your options, and have come up with statistics that back up your reasons as to why your alternative beats the competition. Does it evaluate the action or alternative in terms of criteria? ✓ Does it present the facts and evidence that supports each evaluative ✓ statement? • Conclusions – You need to state the conclusion you have came up with. How did you evaluate the alternatives? And then from there, which alternative best fit your organization. Does it explain the significance from the reader’s viewpoint of your facts? ✓ Does it state the conclusion plain and simple? ✓ • Recommendations – You need to use your experience and knowledge in order to state which option you think should be adopted. Does it advise which course of action or alternative you recommend? ✓ Does it present recommendations which stand out? ✓ Does it suggest specific steps your readers may take to act on each of your ✓ recommendations? - Note: All seven element outlined do not need to be included in the feasibility report depending on audience, circumstance, mission, etc. Also the elements do not need to be in the exact order outlined above. Specifically the conclusion should be mentioned more than just at the end of the report. It should also be summarized in the beginning of the report and in the case the the feasibility report is long, it can be mentioned in the middle as well. - However, there are two improtant features that we have to understand more: Criteria/Constraints: - What to consider in your feasibility study/report. As you begin formulating what you would like to consider you should realize that usually criteria works around one or more of the following questions. - Will your plan or course of action really do what is desired? This is often seen on the technical sides. What you have to ask yourself is whether or not your implementation or change really makes that much of a difference. Lets say you are looking to improve an aspect of your company. Will your change really improve the proficiency and speed of what their trying to do. Or will you find in your study that the change actually slows down production or the efficiency of the company’s workers. This is important to predict beforehand because sometimes an improvement in the workplace is not always an improvement in how a company works. But many of these factors you will 20 not notice until after you complete your study. And in the worst case you may not see negative ailments until after the plan is implemented. - What will it take to implement your course of action? Even though your plan of action may seem correct and efficient on paper, it may not be practical towards your line of work. You must take into account the circumstances that arise in every aspect of a professional setting. What you may find is that in one field your plan may be extremely successful, but in another may be a bust. This can also take place from company to company. As you work at different companies along the same field, you will begin to understand what can be successful in one workplace that may not work in another. Sometimes you have to take into account the amount of changes that will need to be implemented for your plan. Do you need to go through extensive changes in operations, or make upgrades to current equipment or materials that are currently in use or in stock? Sometimes the amount of money that needs to be put into a new project may be much more than the actual amount of benefit that would be received from the changes.You must consider your plan as a cost-benefit analysis. - Cost of implementation. Dollar BillsThis may become the biggest factor in any business decision. How much will it cost? In not only business, but any professional field, the benefits must outweigh the costs in any decision. This is even the case when deciding to work on one aspect of a project compared to the other. When forming criteria for a feasibility report, you must understand the costs if all went as planned. Then you might even want to find out what the cost would be if you had minor or major setbacks. It is important to understand the costs because unless the benefits outweigh the costs, a company will most likely not go through with your proposed plan of action. Also it is important to look into the future of the company. Maybe your plan of action will not be beneficial for the first year in existence, but what about the years following that? This must be considered because like any other decision in business, the original fixed cost may be high but the marginal gains may be high. In that case it may be a good decision for the company to make a change if it is beneficial for the future. Think about health care companies. Would it be beneficial for a company to invest in new equipment even though the upright payment is very high? - Is your idea/product desirable? This is as simple as is your plan going to sell. Will people want to overextend themselves for change, or will they reject what you are trying to do? Sometimes a change or solution must be more than just effective and affordable. You must consider the consumers and people that will be changing. Sometimes many feasible courses of action do not succeed simply because they create effects that drive the consumers away. Because of this, the product or plan does not sell. These undesirable side effects can be as simple as tearing away employee morale. Sometimes even though a plan is promoting and expected to increase productivity, how will the employees react? Many times companies overlook how their employees are going to react to change. But the fact of the matter is that the only way to increase production is to keep employees happy. If they are not pushed to improve the company and their own status then they simply will not find change necessary. Method: - Things to keep in mind: This section of your feasibility report is one of substantial magnitude and importance. This part of your paper demonstrates to the reader what you 21 discovered, through your research, actually matters and has reliability. By telling your audience how you came to know what you have found out and know now, you are demonstrating to them that your results are trustworthy and that they truly hold significance in meaning. With strong methods for finding out your facts, your readers will then feel comfortable and confident to make the necessary changes. - It’s all about the source: The question of what sources to use completely varies from study to study. There are several different types of sources that you could use to find your facts-it all just depends on what you are trying to find answers to. Sources can include (but are not limited to): Academic journals or reports Library research Phone calls Face-to-face interviews Meetings with those who are knowledgeable about the topic or are in your company/organization Surveys (Survey Monkey!) Usability Testing Lab testings - How much is enough? :The length and density of content will vary from each report to the next. You should take into consideration your audience as well as the context and purpose, for which your paper is written. The main goal is to purely get the point across to the readers that what you are reporting has validity, by describing how the means of attaining your information are sound and secure. Make sure that your writing is reader-centered and that they would be satisfied. Doing thus will ensure that your method is long and descriptive enough. - Where does it fit?: The placement of this section of your report will also depend on the type of report that you are writing. If there are only a couple of different methods used throughout your research, it might be a good idea to fit them into the beginning of your report, writing a paragraph for each technique. If you have several, unrelated methods, however, it would be good to place those paragraphs throughout the report, where they would best accompany your analysis or data. - Important note: Sometimes, if it is really obvious how you went about your research, then there might not even be a need to talk about your methods. It is key, though, that your readers always have a clear understanding of the way you obtained your facts and that they are worth trusting. P4. DESCRIBE HOW TECHNICAL SOLUTIONS CAN BE COMPARED. - The purpose of Technical Solution (TS) is to help in the selection of the design and implementing solution to requirements. Technical Solution involves working with product, product components, lifecycle model selection etc. TS focuses on evaluating, selecting solutions, developing details designs and then implementing these designs. - The process of technical solutions: 22 6. Platform: Is the technology you’re considering cloud-based or is it on- premise? “Cloud,” “Hosted,” and “SaaS” are all terms we hear a lot nowadays and there is a reason for that. Internet-based platforms are generally more cost effective, easier to implement, and more secure. 7. Implementation Process: You should begin teeing up your staff for the upcoming changes and even let them be a part of the decision-making process if possible. Be sure to work in enough time to get through the implementation and training process and realize you may need to be flexible because there are a lot of factors that can affect the timing of any technology installation. - Sync: I argue that we should sync all of above factors for success of our project. Every factor has some pros and cos. However, we have to choose advantages and combine together. We have to assess the cost that has to be comfortable with finance of company (Tune Source). If presenting complex requirements, they will pay high costly because implementation process has to prolonged. Therefore, we have to judge to decide a best solution. Moreover, contract length, integration and support factors must co-operate. They give you options when it comes to choosing your contract length, whether it be month-to-month, 1-year, or multi-year agreements. Be sure to ask about contract options as an initial question when you are starting a conversation with any technology provider. A company that has thoughtful and timely customer service is an absolute must. First, look at the ways you can contact customer service. Phone, chat, and email should all be options. Not only will you need reliable support, you’ll likely need continued training as your dealership grows and changes. Be sure to make a list of your current technology solutions and find out whether the new and current solutions can integrate with each other. In coclusion, we have to sync all of factors to provide a best solution that can solve most of customer’s problems and it has to be comfortable with their requirements. 25 REFERENCES: 1. https://www.facebook.com/Stackify and https://www.facebook.com/Stackify . What is SDLC? Understand the Software Development Life Cycle. [online] Stackify. Available at: https://stackify.com/what-is-sdlc/. 2. SearchSoftwareQuality. What is waterfall model? - Definition from WhatIs.com. [online] Available at: https://searchsoftwarequality.techtarget.com/definition/waterfall-model. 3. Tryqa.com. What is Waterfall model- Examples, advantages, disadvantages & when to use it? [online] Available at: http://tryqa.com/what-is-waterfall-model-advantages-disadvantages%20and-when-to-use-it/ 4. GeeksforGeeks. Software Engineering | SDLC V-Model - GeeksforGeeks. [online] Available at: https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/. 5. tutorialspoint.com. SDLC V-Model. [online] www.tutorialspoint.com. Available at: https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm. 6. Guru99.com. What is Spiral Model? When to Use? Advantages & Disadvantages. [online] Available at: https://www.guru99.com/what-is-spiral-model-when-to-use advantages %20disadvantages.html. 7. GeeksforGeeks. Software Engineering | Spiral Model - GeeksforGeeks. [online] Available at: https://www.geeksforgeeks.org/software-engineering-spiral-model/. 8. Ankita Singh. What Is Rapid Application Development (RAD)? [online] Capterra.com. Available at: https://blog.capterra.com/what-is-rapid-application-development/. 9. Filipets, V. Rapid Application Development Model: definition and stages. [online] Theappsolutions.com. Available at: https://theappsolutions.com/blog/development/rad-model/. 10. GeeksforGeeks. Steps in Rapid Application Development (RAD) model. [online] Available at: https://www.geeksforgeeks.org/steps-in-rapid-application-development-rad%02model/? ref=leftbar-rightbar. 11.Autosoft. Things to Consider When Choosing Technology for Your Dealership. [online] Available at: https://autosoftdms.com/choosing-dealership-technology/ 12. www.wibas.com. (n.d.). Technical Solution (TS) (CMMI-DEV). [online] Available at: https://www.wibas.com/cmmi/technical-solution-ts-cmmi-dev. 26