1. Trang chủ
  2. » Luận Văn - Báo Cáo

assignment name software development lifecycles

32 0 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Software Development Lifecycles
Tác giả La Tuan Huy
Người hướng dẫn Nguyen Van Huy
Chuyên ngành Software Development
Thể loại Assignment
Năm xuất bản 2023
Định dạng
Số trang 32
Dung lượng 5,11 MB

Nội dung

References...The Software Development Life Cycle SDLC is a thorough procedure for developing software that includesplanning, analysis, design, deployment, testing, maintenance, and final

Trang 1

PROGRAM TITLE: SOFTWARE DEVELOPMENT LIFECYCLES

UNIT TITLE: UNIT 7

ASSIGNMENT NUMBER: ASSIGNMENT 1

ASSIGNMENT NAME: SOFTWARE DEVELOPMENT LIFECYCLES

Trang 2

ernal verification:

Trang 3

I Introduce

II Theory

1 Software Development Life Cycle (SDLC)

1.1 What is SDLC?

1.2 Presentation of the stages of SDLC

1.3 List some models of SDLC

2 Sequential model

2.1 WaterFall Model

2.2 V Model

3 Two Iterative Models

3.1 Spiral Model

3.2 Iterative Incremental Model

4 Risk management in 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 project 6 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

III Practice

1.Project Presentation

2 Project investigation

2.1 Functional and Non-Functional requirements

2.2 Functional requirements

2.3 Non - Functional requirements

2.4 Project feasibility

3 Software analysis

I Stakeholders

II Input, Output, process descriptors

Trang 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

I.Introduction

The Software Development Life Cycle (SDLC) is a thorough procedure for developing software that includes planning, analysis, design, deployment, testing, maintenance, and finally retirement The software development life cycle (SDLC) offers a framework for managing software development tasks and making sure the finished product satisfies quality and performance standards as well as client expectations Implementing SDLC can be done in a variety of ways, including Waterfall, Agile, and DevOps Every approach has its own traits, and the best one is picked 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 quality objectives 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:

In conclusion, the SDLC is an essential step in the software development process that makes sure the final product satisfies quality and performance standards as well as client needs

II.Theory

1.SoftwareDevelopmentLifeCycle(SDLC)

1.1StatetheconceptofSDLC

+ 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 upgrade specific software

1.2 PresentationofthestagesofSDLC

Trang 5

I Requirements Phase: This is an important phase that affects the construction and development

of 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 prototype

to 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.3ListsomemodelsofSDLC

I Waterfall model

Trang 6

II V-shaped pattern

III Spiral pattern

Trang 7

IV The Agile Model: the Scrum process

2.Sequentialmodel

Trang 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 testing

is 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 toaddress certain problems Moreover, improved versions of the product are issued To bringabout these changes in the surroundings of the consumer, maintenance is performed

Trang 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

2.2VModel

- 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 design

of 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

Trang 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 proposed

in this quadrant

Trang 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

Trang 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

+ Early in the life cycle, several functionalities can be built quickly

+ Results are received frequently and early

+ Planned parallel development is possible

+ Progress is quantifiable

+ 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

Trang 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

4.1PresentingtheconceptofriskinSDLC

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

4.2PresentingtheriskmanagementconceptofmodelsinSDLC

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

Trang 14

● Installation, Operation and Acceptance Testing

7.2Statethecriteriaforassessingfeasibility

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

7.3Statethepurposeofthefeasibilityreport

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

Trang 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 write

it 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

Trang 16

Tax impacts You can evaluate different approaches based on how they would change

your 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 purpose

of this section is to remind your readers how you evaluated each approach before you make your final

recommendation

- 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 not

be 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 be

economically 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 targets

a 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

Ngày đăng: 14/06/2024, 16:20

w