assignment name software development lifecycles

<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

PROGRAM TITLE: SOFTWARE DEVELOPMENT LIFECYCLES

UNIT TITLE: UNIT 7

ASSIGNMENT NUMBER: ASSIGNMENT 1

ASSIGNMENT NAME: SOFTWARE DEVELOPMENT LIFECYCLES

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

ernal verification:

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

1.2 Presentation of the stages of SDLC...

1.3 List some models of SDLC...

4.1 Presenting the concept of risk in SDLC:...

5. Example and explanation of why it is necessary to choose the right development model for the project6. A specific example of a large software effectively applying the Waterfall model...

7. Feasibility report...

7.1 Present the concept of feasibility report :...

7.2 State the criteria for assessing feasibility...

7.3 State the purpose of the feasibility report...

7.4 Explain the importance of feasibility reports...

7.5 Outline the components of the feasibility report...

7.6 Get an example of a specific sample of a feasibility report...

8. Technological solutions in the feasibility report...

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

III. Data Flow Diagram...

IV. ERD...

V. Software requirements tracking...

4. Resolve user requests...

4.1 Definition:...

5. Analysis of software engineering and behavior...

6. State Finite Machine (FSM) và FSM extension...

IV. References...

The Software Development Life Cycle (SDLC) is a thorough procedure for developing software that includesplanning, analysis, design, deployment, testing, maintenance, and finally retirement. The software development lifecycle (SDLC) offers a framework for managing software development tasks and making sure the finished productsatisfies quality and performance standards as well as client expectations. Implementing SDLC can be done in avariety of ways, including Waterfall, Agile, and DevOps. Every approach has its own traits, and the best one ispicked based on the needs of the project and the client. Each step of the SDLC has distinct objectives and results,and each one is crucial in ensuring that the software development project is finished on schedule and meets qualityobjectives. The essential phases of the SDLC are as follows: - Analysis and planning - Design - Deployment -Testing - Maintenance and support - Retirement. To sum up, the SDLC is:

+ SDLC – Software Development Life Cycle is a process followed for a software project,within a software organization. It includes a blueprint that describes how to develop, maintain, change or upgradespecific software.

1.2 PresentationofthestagesofSDLC

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

I. Requirements Phase: This is an important phase that affects the construction and developmentof the software during the development time. In this phase, the analysis department will meetand discuss with customers about the desire to build software.

II. Specification phase: This is the phase that will record the customer's requirements after therequirements phase clearly implements the customer's requirements and realizes it by SRSdocument, also known as "Specification document". The SRS document is very important to thesoftware development process as it covers all requirements for the product to be designed anddeveloped during the entire project life cycle.

department will come up with a common interface as well as the programming department willdesign the detailed interface according to each required function. of cutomer. That is to realizethe functions contained in the SRS document in the form of a prototype. Then use the prototypeto communicate with the customer, when the customer agrees with the interface according to theprototype, then move to the next step.

the customer through the prototype. The programmers will program the functional handling, therequired module will be assigned and then will be transferred to the tester to test the functionsaccording to the testcase built on the SRS document.

V. Testing phase: In this phase, the testers will perform the testing process according to the testcase based on the SRS document, if there is an error, the tester will report the bug to let theprogrammer handle the function. that fixes the error. During this process, testers will have torepeat the process of testing and reporting errors until the software functions work according tothe SRS document or customer requirements.

deployed to the market, but there is an error during user use, the software developmentcompany will have to support and handle it. error. There are two things to keep in mind here:- Sofware repair: Correct errors arising during the use of the customer's software

- Sofware update:

+ Complete maintenance: Modify the software according to the customer's wishes+ Adaptive Maintenance: Modifying software to adapt to a new environment

1.3ListsomemodelsofSDLCI. Waterfall model

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

II. V-shaped pattern

III. Spiral pattern

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

IV. The Agile Model: the Scrum process

2.Sequentialmodel

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

+ System Design – In this step, the required specifications from the first phase are examined,and a system design is created. This system design aids in determining the overall systemarchitecture as well as the hardware and system requirements.

+ Implementation- The system is first developed in discrete programs known as units, whichare then combined in the following phase, with input from the system design. Unit testingis the process of developing and evaluating each unit for functionality.

+ Integration and Testing- When each unit has been tested, all those created during theimplementation phase are merged into a system. The entire system is tested for errors andfailures after integration.

+ Deployment of system - Once the product has undergone functional and non-functionaltesting, it is either published to the market or deployed in the customer's environment.+ Maintenance - Many problems can arise in a client environment. Patches are published to

address certain problems. Moreover, improved versions of the product are issued. To bringabout these changes in the surroundings of the consumer, maintenance is performed.

- Pros:

+ Proven method with a perfectly logical sequence of steps

+ Feasibility analysis at all phases to eliminate bottlenecks and data storage.+ Concrete output at the end of each stage

+ DLC that everyone in the company can easily understand- Cons:

+ Rigid, not suitable for modern DevOps where flexibility is required, changing code aftereach step.

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

+ Not a good choice for short projects as there is no way to skip steps. Once the steps arecompleted, it is unlikely that changes will be made.

+ Projects with requirements, uncertainties, or changes are not ideal+ Long construction time

- Definition: Is a Waterfall model but modified. The development branch is mirrored by the testbranch. Forking becomes two interdependent processes that allow you to eliminate risk and improve the quality ofthe final product, but it does not speed up development.

- ModelStage: Each validation phase has a fixed validation phase and the diagram of the model isshown as V.

+ Analysis of requirements: This phase contains detailed communication with the customer tounderstand their requirements and expectations. This stage is known as Requirement Gathering.

+ System design: This phase contains the system design and the complete hardware andcommunication setup for developing the product.

+ High-quality design: System design is broken down further into modules taking up differentfunctionalities. The data transfer and communication between the internal modules and with the outside world(other systems) is clearly understood.

+ Low-end design: In this phase, the system breaks down into small modules. The detailed designof modules is specified, also known as Low-Level Design (LLD).

+ System test: System testing test the complete application with its functionality, inter dependency,and communication.It tests the functional and non-functional requirements of the developed application.

+ Acceptance test: UAT is performed in a user environment that resembles the productionenvironment. UAT verifies that the delivered system meets user’s requirement and system is ready for use in realworld.

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

- Pros

+ Phases are finished one at a time under this model, which requires extreme discipline.+ works effectively for smaller projects with clearly defined criteria.

+ Straightforward, clear, and convenient to use.

+ Because of the model's rigidity, it is simple to manage. Specific deliverables and a reviewprocess are included at each phase.

+ high uncertainty and danger.

+ Unsuitable as a model for intricate and object-oriented projects.+ Ineffective model for continuing, protracted projects.

+ Not appropriate for projects where there is a moderate to high probability of requirementschanging.

+ It is challenging to go back and update a functionality once an application has entered thetesting phase.

+ It takes till the end of the life cycle for any working software to be generated.3.TwoIterativeModels

3.1 SpiralModel

- Definition: It is based on Deming's classic PDCA (Plan-Do-Check-Act) cycle. This issimilar to iterate/increment. It also assumes that it is iterative and that the overall task is split into smaller iterations.However, improvements are made at every step of the SDLC. Each iteration begins with an assessment of potentialrisks and a plan to avoid those risks.

- The spiral model is a risk-driven SDLC strategy. This model emphasizes the repetition of its fourcorestages:

+ Determine objectives: Requirements are gathered from the customers and the objectives are identified,elaborated, and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposedin this quadrant.

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

+ Identify and resolve risks: During the second quadrant, all the possible solutions are evaluated to selectthe best possible solution. Then the risks associated with that solution are identified and the risks are resolved usingthe best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution.

+ Development and testing (typically involves some form of prototyping): During the third quadrant, theidentified features are developed and verified through testing. At the end of the third quadrant, the next version ofthe software is available.

+ Evaluate results and plan the next iteration: In the fourth quadrant, the Customers evaluate the so fardeveloped version of the software. In the end, planning for the next phase is started.

+ Adjustments to requirements are possible.+ permits the usage of prototypes extensively.+ More precise requirement capturing is possible.+ People notice the system quickly.

+ The riskier portions of the development process can be developed early and in smaller chunks,which improves risk management.

+ That is harder to manage.

+ The project's end may not be recognized right away.

+ Not appropriate for little-risk or low-risk initiatives, and it might be costly for modest enterprises.+ Procedure is difficult

+ Spiral might continue forever.

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">

+ Several intermediary steps necessitate a lot of paperwork.3.2 IterativeIncrementalModel

-Definition: The model consists of small iterative steps aimed at relatively quick andcheap production, followed by testing and refinement. Each iteration creates a better version of the same productuntil the final version is ready. Essentially, this approach repeats the development process.

- The first version was an incomplete product and did not meet most software requirements. Eachsubsequent version adds even more features to the product. Eachiterationgoesthroughthefollowingphases:

+ Initiation phase (needs analysis, project goals a,nd scope).+ Build phase (designing a functional product architecture).+ Build phase (write architecture code and build deployable product)+ Migration phase (from production to production).

- Each iteration goes through a validation process and requires feedback from users or stakeholders. Thelatest version has undergone rigorous testing and provides a version of the product that meets all DDSrequirements.

+ It is less expensive to alter the criteria or scope.

+ It is simple to test and troubleshoot throughout shorter iterations.

+ Each iteration is a manageable milestone where risks are identified and dealt with.+ Risk management is simpler since high risk tasks are completed first.

+ Delivery of an operational product occurs with each increment.

+ The issues, difficulties, and dangers noted from each increment can be used or applied tothe following increment.

+ Analysis of risks is preferable.+ It accommodates shifting demands.+ Lower initial operating time.

+ More suited for significant and vital projects.

+ Early software production within the life cycle makes it easier for customers to evaluateand provide feedback.

+ Perhaps more resources are needed.

+ Despite the lower cost of modification, it is not well suited to evolving requirements.+ Greater management focus is needed.

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

+ Because not all requirements are acquired at the beginning of the complete life cycle,system architecture or design challenges may develop.

+ The system as a whole may need to be defined in order to define increments.+ For lesser projects, insufficient.

+ There is higher management complexity.

+ A risk is that the project's conclusion might not be known.+ Risk analysis requires highly qualified personnel.

+ The risk analysis phase is very important to the development of projects.4.RiskmanagementinSDLC

A risk is an activity or incident that can affect the success of a software development project forwhich the project may suffer, and the total amount of risk for a particular project will account forboth probability and risk. scale of loss

Risk management means preventing and minimizing risk. First, you must define and plan. Then, beready to act when risks arise, drawing on the experience and knowledge of the entire team tominimize the impact on the project.

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

● Installation, Operation and Acceptance Testing● Maintenance

● Disposal

A feasibility report is a report that evaluates a set of proposed project paths or solutions todetermine if they are viable. The person who prepares a feasibility report evaluates the feasibility of differentsolutions and then chooses their recommendation for the best solution. They then present the feasibility report totheir company and make their recommendation.

feasibility, a rough order of magnitude (ROM) estimate is commonly performed.

For example, medical software dealing with protected health information (PHI) mustmeet HIPAA rules. Besides that, you have to explore what legal risks there are andhow they can impact your project.

should be implemented, and what efforts should be taken to maintain it. Say you’regoing to launch a global e-commerce platform. Then you need to have localwarehouse, local service teams and in some cases even local websites in each country.It’s very difficult to realize operationally and might make no sense at all – though theinitial idea looks commercially attractive and technically feasible

The purpose of a feasibility report is to determine the feasibility of solutions or projectpaths and choose the best option. The feasibility report serves to break down different approaches to a problem orproject and help reader understand the feasibility of each approach. Based on the evaluation outlined in the report,readers can decide whether to take the report’s recommendation of the best approach. This thorough analysis ofdifferent approaches can help companies make the best decisions on projects and problems.

7.4Explaintheimportanceoffeasibilityreports● Improves project teams focus● Identifies new opportunities

● valuable information for a “go/no-go” decision

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

● Narrows the business alternatives

● Identifies a valid reason to undertake the project● Enhances the success rate by evaluating multiple parameters● Aids decision-making on the project

● Identifies reasons not to proceed

● Apart from the approaches to feasibility study listed above, some projects alsorequire other constrains to be analyzed

● Internal project Constraints: Technical, Technology, Budget, Resource, etc.● Internal Corporate Constraints: Financial, Marketing, Export,etc.● External Constraints: Logistics, Environment, Laws and Regulaions, etc.7.5Outlinethecomponentsofthefeasibilityreport

+ Executive summary

One of the first components of feasibility report is the executive summary. Anexecutive summary can help your reader understand the main points of your report andread an overview of the report. Your executive summary can be brief and be sure to writeit clearly and concisely. Some elements to consider including in your executive summaryare:

● Brief description od what’s in your report, including the problem you’resolving or the project you’re working on

● Notes on the main ideas from your research or important information fromyour report

● Concise explanantion of how the project or problem relates to the overallmission of your company

The goal of writing your executive summary is to keep it brief andunderstandable, as you can go into more detail in your report. Although theexecutive summary is one of the first elements of the report, many peoplechoose to write their executive what information to include in it.- Introduction: Another important component of a feasibility report is the introduction.Following the executive summary, you can write an introduction that explains what the problem or project is andthe proposed approaches. Like your executive summary, your introduction can be general and brief as you canexplain more details later in the report.

- Background and context: A feasibility report should also include background andcontext. This section is important to help people who read the report understand important contextual information.For example, if you’re discussing different approaches for a project, you could include the history and goals of theproject in your background and context section. If you’re evaluating different solutions to a problem, you couldexplain where the problem came from and how it affects your company. This can prime your audience tounderstand the feasibility of different approaches.

- Evaluation criteria: You can also include a report section that explains your evaluationcriteria. This section helps the reader of your understand how you evaluated the feasibility of different approacheesand why you arrived at your recommendation. Your evaluation ctriteria may include:

taking action, so financial costs may be one of the criteria in yourfeasibility report

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

Tax impacts You can evaluate different approaches based on how they would changeyour company’s taxes as another criterion

so you could evaluate how different approaches would influence yourcompany’s public perception in your feasibility report

including the enviromental effects of an approach in your report.

could evaluate the resources needed as one of your criteria.

- Evaluation of solutions: A key section of a feasibility report is the evaluation of solutions section. This sectionaccomplishes the purpose of a feasibility report, which is to determine the feasibility of solutions and project paths.The evaluation section is where you compare potential approaches based on your evaluation criteria. Thisevaluation process leads you to make your recommendation on the best approach.

- Conclusion: You can summarize your report and reiterate your main points in a conclusion section. This sectioncan be brief and include a quick description of the pros and cons of each of the approaches discussed. The purposeof this section is to remind your readers how you evaluated each approach before you make your finalrecommendation.

- Final recommendation: The last section of a feasibility report contains your direct recommendation for the bestpath forward. In this section, which can be brief, you can explain whether the solution is feasibility and why youbelieve it’s the right choice. The key to writing the final recommendation section is directly stating what yourrecommendation is and why.

7.6 Getanexampleofaspecificsampleofafeasibilityreport

-Technicalfeasibility:Different technical feasibility criteria such as platform compatibility, scalabilityand security may lead to different feasibility report results. For example, if a software project requires a particularplatform such as iOS or Android, it may not technically be viable if the development team has no experience withthat platform. Similarly, if a software project requires high scalability or stringent security requirements, it may notbe technically viable if the proposed development approach or technology stack cannot meet those requirements. .

-Economic:Various economic feasibility criteria such as market size, competition, and pricingstrategies can lead to different results in feasibility reports. For example, if a software project targets a niche marketwith limited revenue potential, it may not be economically viable if the development costs exceed the potentialrevenue. Similarly, if a software project faces stiff competition from established players, it may not beeconomically viable if the market is already saturated. Finally, if the software project has high development costsand a low target price, it may not be economically viable if the profit margin is too small.

-Operationalfeasibility:Different operational feasibility criteria, such as user requirements,usability, and support, can lead to different results in the feasibility report. For example, if a software project targetsa user base with very specific needs, it may not be operationally viable if the proposed functionality does not meetthose needs. Similarly, if a software project is difficult to use or requires extensive training, it may not be

</div>