Download Asm1 SDLC Software development life cycle and more Summaries C programming in PDF only on Docsity!
ASSIGNMENT 1 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 9 : Software Development Life Cycle Submission date Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name LÝ NGUYỄN TUẤN KIỆT Student ID BC Class IT05101 Assessor name TRẦN VĂN NHUỘM Student declaration I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a false declaration is a form of malpractice. Student’s signature KIỆT Grading grid P1 P2 P3 P4 M1 M2 D1 D
Summative Feedback: Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
- Image
- I. Introduction
- II. Describe two iterative and two sequential software life cycle models(P1)
- III. Describe, with an example, why a particular life cycle model is selected for a development environment(M1)
- IV. Explain how risk is managed in the Spiral life cycle model. (p2).
- V. Explain the purpose of a feasibility report(P3)
- VI. Describe how technical solutions can be compared.(P4)
- VII. Discuss the components of a feasibility report(M2).
- VIII. Discuss the merits of applying the waterfall model to a large software development project(D1)
- Conclusion
- References
- Image 1 : Waterfall model Image
- Image 2 :Agile model
- Image 3 : V-model
- Image 4 :Prototyping model
- Image 5 : Spiral model
- Image 6 : Risk matrix
- Image 7 : Types of Feasibility reports
I. Introduction
Product excellence and customer satisfaction with the system are always top considerations for companies and businesses. A system must pass through a number of precise and demanding stages in order to be able to build one that satisfies all requirements for entering the market. All of these phases make up the idea of the software development life cycle. In this study, models representing different phases of the software development life cycle will be examined, and the model that most closely matches the viewpoint of the Tune Source firm will be selected. The paper will also look at risks and how to approach and handle them. The final piece will cover the value of a feasibility study in any system and how it fits into the Tune Source project.
Image 1 : Waterfall model The Waterfall model's successive phases are: Requirement Collecting and Analysis — At this stage, all potential requirements for the system to be developed are gathered and recorded in a requirement specification document. System Design – In this phase, the need specifications from the previous phase are researched and the system design is created. This system design aids in determining the overall system architecture as well as the hardware and system requirements. Implementation – The system is initially created as a collection of short programs known as units, which are then combined in the next phase, using input from the system design. Unit testing is the process of developing and evaluating each unit for functionality. Integration and Testing All the units created during the implementation process are tested before being integrated into a system. The entire system is tested for errors and failures after integration. System deployment – After functional and non-functional testing, the product is either provided to customers or deployed in their environments. Maintenance – The client environment occasionally experiences problems. Patches are made available to address those problems. Moreover, improved versions of the product are issued. To bring about these changes in the surroundings of the consumer, maintenance is performed.
The progression is perceived as flowing slowly downward (like a waterfall) through the stages as all of these phases cascade to one another. The "Waterfall Model" gets its name because the following phase doesn't begin until the prior phase's established set of goals have been met and it has been approved. Phases do not cross over in this model. For example: Corporate applications like Customer Relationship Management (CRM) systems, Human Resource Management (HRMS), Supply Chain Management Systems, Inventory Management Systems, Point of Sales (POS) systems for Retail chains, etc. were once created using the Waterfall paradigm. Up to the year 2000, the waterfall approach was extensively utilized in the creation of software. Even after the 2001 publication of the Agile Manifesto, many organizations employed the Waterfall methodology up to the past ten years. Other industries that have utilized the waterfall approach include banking, healthcare, nuclear facility control systems, and space shuttles. The Waterfall SDLC model is used because: The requirements are clearly documented. The product description is stable. The technology stack is predefined, making it not dynamic There are no unclear requirements. The project is brief It also provides a lot of benefits and drawbacks for users: ADVANTAGES : Easy to use and comprehend. Because of its rigidity, management is made simple because each phase has a clear outcome and process evaluation. Each stage of development happens in turn. The essential phases of the development cycle are simple to identify. Simple to categorize and prioritize chores. Suitable for little or midsize projects with precise and unambiguous needs. DISADVANTAGES :
Characteristics: It predetermines the number, length, and scope of each repetition. Phases of the waterfall paradigm are requirements gathering, Requirements Design, Requirements Implementation, Develop/Iteration, Testing, deployment, and Feedback. Advantages: To communicate with clients, one-on-one interaction is employed. Provides a really useful approach to creating software. The agile software engineering paradigm enables you to produce useful designs and meet the demands of the company. New iterations of usable software are released every week. It offers quick, workable partial solutions. Making modifications is a smart idea at any time. You may reduce the overall length of development time by utilizing this Agile Model. It permits concurrent development and delivery in a comprehensive planned setting. The completed product is created and ready for use in a few of weeks. Disadvantages: There is a larger danger to sustainability, maintainability, and extensibility. Self-organization and tight cooperation can not be compatible with an organization's corporate culture. Design and documentation don't get much thought. If the client doesn't give clear instructions, the development team can be misled. Not the ideal strategy for handling complex dependencies.
3. V-model The V-model is an SDLC framework where processes are executed sequentially in a V-shape. The Verification and Validation Model is another name for it. A testing phase is linked to each relevant development step in the V-Model, which is an extension of the waterfall model. This implies that there is a testing phase that is directly related to each and every phase of the development cycle. This is a very structured approach, and the start of the subsequent phase only occurs after the conclusion of the preceding phase. According to the V-Model, the associated testing phase of the development phase is scheduled concurrently. Hence, Validation stages are on the other side of the "V" than Verification phases.
The two sides of the V-Model are joined during the coding phase. The phases of a V-Model of the SDLC are shown in the following diagram. Image 3 : V-model The V-Model contains numerous Verification steps, each of which is described in more detail below: Business Needs Analysis on page 9 The needs for the product are first grasped from the viewpoint of the client at this phase of the development cycle. The consumer is extensively communicated with at this phase in order to ascertain his expectations and precise needs. Given that most consumers are unsure about their specific wants, this is a crucial task that has to be managed carefully. Although business requirements may be utilized as an input for acceptance testing, the design planning for the acceptance test is completed at this stage. System Design: After you have precise and comprehensive product requirements, it's time to design the entire system. The system design will include a thorough grasp of the hardware and communication configuration for the product that is currently being developed. On the basis of the system design, the system test plan is created. By doing this sooner, more time is available for the actual test run. Architectural Design:
majority of software and hardware compatibility problems can be discovered during the system test execution. Acceptance Testing: Acceptance testing is linked to the business requirements analysis phase and entails testing the product in a user environment. Acceptance testing reveal compatibility concerns with other systems in the user environment. It also detects non-functional faults in the real user environment, such as load and performance flaws. The V-Model application is essentially identical to the waterfall model, since both models are sequential in nature. Because it is typically costly to go back and make modifications, requirements must be very explicit before the project begins. Because medical development is a highly regimented sector, this paradigm is often adopted. The following are some of the most appropriate circumstances for using the V- Model application. The requirements are fully defined, documented, and fixed. The product definition is consistent. The project team understands the technology and it is not dynamic. There are no ambiguous or unclear criteria, and the project is brief. The Benefits and Drawbacks of the V-Model: ADVANTAGES: This is a very disciplined methodology, with each Phase performed one at a time. It works best for smaller projects with well-defined criteria. Easy to grasp and use. Because of the model's rigidity, it is simple to manage. Each phase includes its own set of deliverable and a review procedure. DISADVANTAGES: Uncertainty and high risk. Easy to grasp and use. Not suitable for sophisticated and object-oriented programs.
Bad model for long-term projects. Not appropriate for projects with a moderate to high risk of changing needs.
4. Prototyping model A working model with limited functionality is a prototype. The prototype is an additional task that should be taken into account when calculating the effort because it may or may not contain the exact logic that will be utilized in the finished software application. Prototyping allows users to examine and test developer proposals prior to their implementation. Additionally, it helps in understanding user-specific requirements that the product developer might not have taken into account. How this model is used: Listing of Minimum Requirements Understanding the most basic product requirements is a necessary step in this process, especially with regard to user interface. At this point, it is possible to ignore some of the more intricate interior design elements as well as exterior elements like performance and security. Creating the first prototype Here, the first Prototype is developed, the most fundamental requirements are presented, and user interfaces are provided. Some features might not operate internally in the same way as the software itself was designed to. To give the consumer the same look and feel as the prototype produced, workarounds are used. Examining the prototype The generated prototype is subsequently presented to the client and other project stakeholders. The feedback is gathered methodically and used to enhance the product that is currently under development. Improve and revise the prototype. Depending on factors like time and budget constraints, as well as the technical viability of the actual implementation, the client's feedback and review comments are taken into consideration during this stage, and some talks may be had with the client. Once the new Prototype has been built and the agreed-upon improvements have been incorporated, the cycle is repeated until the customer's expectations are met. The prototype model has the following benefits, among others: There was more user contact even before the product was released.
5. Spiral model The spiral model blends the notion of repeated development with the waterfall model's methodical, regulated characteristics. This spiral model is a hybrid of the iterative development process model and the sequential linear development model, often known as the waterfall model, with a heavy emphasis on risk analysis. It enables incremental product launches or incremental refining with each iteration around the spiral. The spiral model is divided into four stages. Spirals are iterations in which a software project goes through certain phases repeatedly: Identification : In this phase, the baseline spiral is used to collect the business needs. This phase is used to identify system requirements, subsystem requirements, and unit requirements in future spirals as the product grows. This phase also includes continual contact between the client and the system analyst to understand the system requirements. The product is launched in the specified market at the conclusion of the spiral. Design : The Design process begins with conceptual design in the baseline spiral and progresses to architectural design, logical module design, physical product design, and final design in successive spirals. Construct of build: The Build phase refers to the actual software product manufacturing at each spiral. In the baseline spiral, while the idea is still being thought about and the design is being developed, a POC (Proof of Concept) is created to get user input. Next, in following spirals with greater clarity on requirements and design specifics, a functioning model of the program known as a build with a version number is generated. These prototypes are submitted to the buyer for review. Evaluation and risk assessment: Risk assessment include identifying, assessing, and monitoring technical feasibility and management risks such as timetable slippage and cost overrun. After testing the build, the customer reviews the program and offers feedback at the conclusion of the first iteration. The picture below depicts the Spiral Model and lists the tasks in each step.
Image 5 : Spiral model The Spiral Model is extensively employed in the software business because it is in sync with the natural development process of any product, i.e. learning with maturity with little risk for the client and development company. The following tips show how to utilize a Spiral Model: When there is a financial limitation and risk assessment is critical. For projects with medium to high risk. Long-term project commitment due to the possibility of changes in economic priorities as requirements change over time. The customer is unsure of their requirements, which is common. Requirements are complicated and must be evaluated for clarity. A new product line that should be introduced in stages to get enough client input. Substantial modifications to the product are expected during the development period. ADVANTAGE
III. Describe, with an example, why a particular
life cycle model is selected for a development
environment(M1)
Waterfall Model: Waterfall model is sometimes referred to as waterfall model. The Waterfall model, known as one of the simplest project management models accessible today, is a project management approach based on a sequential and sequential design process. The phases of the project are completed one after the other under the Waterfall model. A new phase begins only when the preceding one has been finished. As an example, consider the waterfall paradigm in system design: Analysis of requirements. System design 3.System performance 4.System testing. System installation. Upkeep of the system. The Case for Using the Model in a Development Environment:
The Waterfall approach is suitable when the implementer knows the project needs well and demands great clarity and stability, such as: Grasping technological development. Remove any criteria that are confusing or unclear. There are numerous development resources available, as well as a high degree of experience and technology; this may be appropriate for a modest, short-term project. Upkeep of the system. V model: The V Model is a highly disciplined SDLC methodology that includes a testing phase concurrent with each development phase. The V-model is an extension of the waterfall paradigm in which testing is done sequentially on each step in tandem with development. In system design, consider the V model: The Case for Using the Model in a Development Environment: The V-model was developed to address the shortcomings of the waterfall model. The V-pattern enables a parallel testing method for each phase of the development process, as opposed to testing just after the code development is complete, as in the waterfall paradigm. There are further benefits: Straightforward, user-friendly, and time-saving Provide detailed strategies and actions for the testing process.
