Agile rõ ràng thông tin

a) Requirement characteristics:

 Reliability:
 I find with all confidence, this project fits the Agile model best
because:
 -The advantages of aglie are: Agile teams are motivated and self-organized to be able to deliver better
results from development projects. Agile software development methodology ensures that the quality
of the development is maintained Flexible changes can be made in each iteration without interfering
with what was developed before.
- Working software demos, which are viewed as a more effective approach to
communicate with customers throughout the working software phase, are prioritized
instead of solely depending on documentation.

- The customer's collaboration is crucial to obtaining the accurate product

specifications because it is challenging to meet requirements from the start of the
project for a variety of reasons.

-Rapid response and continual improvement are stressed in the final stage of Agile
model development, responding to change.
 Types and number of requirements:
- According to the topic:
-Face-to-face communication is the most productive way. Entrepreneurs and
programmers work together every day.

- Any necessary changes, no matter how last-minute, will be made. Keep your
attention focused on both technical proficiency and aesthetic attractiveness.
Regularly adjust to shifting circumstances.
 How often the requirements can change:
- Agile models' adaptability enables for quick changes in requirements. Agile
techniques, which take a practical approach to software development, promote
collaboration and cross-training as well as quick function construction and
demonstration because they can manage both static and dynamic bridges.

Agile methodologies might result in early iterations of functional solutions. The

authorities select a good model for dealing with issues that are both dynamic and
controllable.
 Can the requirements be defined at an early stage: Agile paradigm allows for continuous
development and delivery within a bigger, planned environment because to its simple usage and few
rules. Agile is better because it gives developers more freedom than Waterfall or the V-model.

b) Development team:
 Team size: (Small/Average/Large) ( My team is a professional)
c) Level of understanding of user requirements by the developersAgile is an excellent fit for the team
since it is more team-based than Waterfall, which helps to improve cross-training and
interdepartmental communication. Making decisions that will have a significant impact on the
course of the business still falls under the purview of the team lead.
d) User involvement in the project: (Small/Average/Large): ( cứ để là trung bình)
- Customers should be actively involved in all stages of development. They are in charge of providing,
prioritizing, and assessing the requirements and iterations of the new system.
 - It is common for the project's specifications to alter often. If a client is prepared to meet with a
software development team at any time, the highly competent and experienced Agile team is
constantly on hand. This Agile project calls for a small team and a modest project.
e) Conclusion: In light of the aforementioned evaluation and the regular flow of needs, I think the
Agile model is the most suitable in this situation. Given that the requirements system is adaptable and
open to change at any time, deploying the system immediately rather than gradually is the proper
course of action.

Agile:
a) Đặc điểm yêu cầu:

 Độ tin cậy: Với tất cả độ tin cậy, dự án này phù hợp với mô hình Agile vì: (copy 1 hoặc 2 gạch dưới)
- Thay vì chỉ dựa vào tài liệu, các bản demo phần mềm hoạt động được coi là cách tốt nhất để giao
tiếp với người tiêu dùng trong giai đoạn phần mềm làm việc.
- Bởi vì các yêu cầu không thể có được đầy đủ ngay từ đầu dự án vì nhiều lý do, sự hợp tác của
khách hàng là rất quan trọng để có được thông số kỹ thuật sản phẩm chính xác.
- Giai đoạn cuối cùng của phát triển mô hình Agile, Đáp ứng với sự thay đổi, nhấn mạnh phản ứng
nhanh với sự thay đổi và cải tiến liên tục.

 Các loại và số lượng yêu cầu: (theo như đề bài ta có : liệt kê các requament ra + 1 trong 2 gạch dưới
)
- Phương tiện giao tiếp hiệu quả nhất là trực tiếp. Hợp tác hàng ngày giữa doanh nhân và lập trình
viên.
- Bất kỳ điều chỉnh nhu cầu nào, bất kể vào phút cuối, sẽ được đáp ứng. Duy trì sự tập trung vào cả
năng lực kỹ thuật và sự hấp dẫn thẩm mỹ. Thích ứng với các điều kiện thay đổi một cách thường
xuyên.

 Tần suất các yêu cầu có thể thay đổi: (theo tôi thấy yêu cầu không rõ ràng lắm nên copy 2 cái gạch
dưới)
- Tính linh hoạt của các mô hình Agile cho phép thay đổi nhu cầu nhanh chóng. Một cách tiếp cận
thực tế để phát triển phần mềm, các phương pháp tiếp cận nhanh nhẹn khuyến khích làm việc
theo nhóm và đào tạo chéo, cũng như tạo và trình diễn chức năng nhanh chóng, bởi vì nó có thể
xử lý cả yêu cầu tĩnh và động,
- Phương pháp nhanh nhẹn có thể tạo ra các lần lặp lại sớm các giải pháp làm việc. Một mô hình
tốt được chính quyền lựa chọn khi xử lý các tình huống vừa năng động vừa có thể quản lý được.

 Các yêu cầu có thể được xác định ở giai đoạn đầu không: Do các quy tắc hạn chế và dễ sử dụng, mô
hình Agile cho phép phát triển và phân phối liên tục trong bối cảnh kế hoạch tổng thể. Agile vượt trội
hơn so với Waterfall hoặc V-model vì nó mang lại cho các nhà phát triển sự tự do hơn.

b) Nhóm phát triển:

 Quy mô nhóm: (Nhỏ / Trung bình / Lớn)(như ta thấy
 Mức độ hiểu biết về yêu cầu của người dùng bởi các nhà phát triển: Do Agile là một mô hình dựa
trên nhóm nhiều hơn Waterfall, nó lý tưởng để cải thiện đào tạo chéo và hợp tác giữa các bộ phận và
 do đó, phù hợp với nhóm. Các quyết định có tác động đáng kể đến tương lai của công ty vẫn được
đưa ra bởi trưởng nhóm.
c) Sự tham gia của người dùng vào dự án: (Nhỏ / Trung bình / Lớn):
- Trong suốt quá trình phát triển, khách hàng nên tích cực tham gia. Công việc của họ là cung cấp,
ưu tiên và đánh giá các nhu cầu và lặp lại của hệ thống mới.
- Không có gì lạ khi các yêu cầu của dự án thay đổi một cách thường xuyên. Nếu khách hàng háo
hức gặp gỡ nhóm phát triển phần mềm bất cứ lúc nào, đội ngũ Agile có trình độ cao và giàu kinh
nghiệm luôn sẵn sàng. Dự án Agile này đòi hỏi một nhóm nhỏ và do đó là một dự án khiêm tốn.
d) Kết luận: Dựa trên đánh giá đã nói ở trên, tôi cảm thấy rằng mô hình Agile là cách tiếp cận phù hợp
nhất trong tình huống này do việc cung cấp các yêu cầu thường xuyên. Nó phù hợp để triển khai hệ
thống ban đầu thay vì xây dựng nó theo từng giai đoạn vì hệ thống yêu cầu có thể thích ứng và có thể
sửa đổi bất cứ lúc nào.

Waterfall:không rõ ràng
a) Requirement characteristics:
 Reliability:
With all the reliability, this project are suitable for the Waterfall because:
- The Waterfall Model was the first to use Process Models. The phrase "linear-sequential life cycle
model" is also used to express this idea. Learning and mastering it are a snap.

- In a waterfall model, each stage must be finished in its entirety before going on to the next. Projects
with fewer than a year's worth of development time and defined criteria make excellent candidates
for this paradigm of software development.

- This paradigm should only be applied when the requirements are well-defined, constant, and
explicit.
 Types and number of requirements:
- The team gathers the requirements from the business analyst and evaluates them in this phase. Now
that the requirements have been stated, more information is available.

- The Business Analysts document the requirements following a client interview. The project team
must respond to the following inquiries that were not included in the requirements document after
they have read and studied the requirements.

 How often the requirements can change:

This is the situation as a result of the stringent regulations that must be adhered to.

As a result, these projects' requirements are well defined in advance, and contracts detail
precisely what must be supplied after the project is finished.
Since it is difficult to make modifications to designs once they have been finished, the Waterfall
approach provides the advantage of allowing for earlier design alterations. Easy.

- Appropriate for projects with a tight time frame: This modification can be accomplished without
the use of any code or implementation. The Waterfall approach is ideal for projects involving
 teams and organizations that work best when deadline pressure is applied because of its
sequential nature.
Team members will find it easier to grasp and follow the timeline if it is broken down into particular
timeframes. A timeframe for the entire process and the designation of a few precise deadlines or
milestones for each step facilitate the researcher's job.
 Can the requirements be defined at an early stage:
- The rigor of the model makes it easy to track the project's progress.

Phases are finished using this technique in the specified order. Do not combine the stages.

- Smaller projects with properly specified and understood needs can benefit from the waterfall
approach.
b) Development team:
 Team size:
 Level of understanding of user requirements by the developers:
- The architect and other team leaders are responsible for the high-level and low-level software
architecture of the project. For the banking application to be accessible at all times, the system will
have redundant backup and failover options. Both high-level and low-level design papers are sketched
up by the architect.
c) User involvement in the project: (Small/Average/Large)
d) Conclusion: In conclusion, I think a waterfall method would be better because the project's
requirements are explicit and aren't anticipated to change. In addition, waterfall was employed in a
wide range of sectors, including banking, healthcare, nuclear power plants, and space shuttles. Staged
development is not necessary because the system requirements do not specify which components
should be implemented first.

Waterfall:
a) Đặc điểm yêu cầu:
 Độ tin cậy:
Với tất cả độ tin cậy, dự án này phù hợp với Thác nước vì:
- Mô hình quy trình lần đầu tiên được giới thiệu trong Mô hình Thác nước. Thuật ngữ "mô hình
vòng đời tuyến tính-tuần tự" cũng được sử dụng để mô tả khái niệm này. Đó là một làn gió để
học và làm chủ.
- Sử dụng mô hình thác nước, mỗi giai đoạn phải được hoàn thành đầy đủ trước khi giai đoạn tiếp
theo có thể được bắt đầu. Các dự án chưa đầy một năm tuổi và không có yêu cầu mơ hồ là ứng
cử viên lý tưởng cho mô hình phát triển phần mềm này.
- Chỉ thích hợp để áp dụng mô hình này nếu nhu cầu được biết đến, được xác định rõ ràng và
không thay đổi.
 Các loại và số lượng yêu cầu:
- Nhà phân tích kinh doanh thu thập các yêu cầu và nhóm phân tích chúng trong giai đoạn này.
Trong giai đoạn này, các yêu cầu được viết ra và có thể thu được nhiều giải thích hơn.
- Các yêu cầu được ghi lại bởi các Nhà phân tích kinh doanh sau khi họ đã nói chuyện với khách
hàng. Nhóm dự án yêu cầu câu trả lời cho các câu hỏi sau, không có trong giấy yêu cầu, sau khi
xem qua và phân tích các yêu cầu.
 Tần suất các yêu cầu có thể thay đổi: ( theo đề bài ta thấy các yêu cầu đã rõ ràng không cần thay đổi
+ copy 5 gạch dưới)
- Điều này là do các quy định và tiêu chuẩn nghiêm ngặt phải được tuân thủ.
 - Do đó, các yêu cầu đối với các dự án này đã được biết đến trước và các hợp đồng quy định chính
xác những gì phải được giao khi dự án hoàn thành.
- Các sửa đổi thiết kế có thể được thực hiện sớm hơn trong cách tiếp cận Thác nước, điều này có
lợi vì những thay đổi thiết kế sau này rất khó thực hiện. Dễ.
- Để thực hiện thay đổi này, không cần bất kỳ mã hoặc triển khai nào. - Thích hợp cho các dự án có
thời hạn chặt chẽ: Tính chất tuần tự của mô hình Thác nước phù hợp với các dự án liên quan đến
các nhóm và tổ chức phát triển mạnh khi có thời hạn.
- Các thành viên trong nhóm sẽ có thể dễ dàng nắm bắt và theo dõi dòng thời gian nếu nó được
chia thành các thời điểm cụ thể. Hơn nữa, công việc của nhà nghiên cứu được thực hiện dễ dàng
hơn bằng cách có một mốc thời gian cho toàn bộ quá trình và bằng cách thiết lập một vài thời
hạn hoặc mốc quan trọng cụ thể cho từng giai đoạn.
 Các yêu cầu có thể được xác định ở giai đoạn đầu:
- Do sự cứng nhắc của mô hình, thật đơn giản để theo dõi tiến độ của dự án.
- Các giai đoạn được thực hiện tuần tự theo mô hình này. Không trộn lẫn các pha.
- Đối với các dự án nhỏ hơn với nhu cầu được xác định rõ ràng và được hiểu rõ, mô hình thác nước
hoạt động tốt.
b) Nhóm phát triển:
 Quy mô nhóm:
 Mức độ hiểu biết về yêu cầu của người dùng bởi các nhà phát triển:
- Kiến trúc phần mềm cấp cao và cấp thấp của dự án là trách nhiệm của kiến trúc sư và các thành
viên cấp cao khác trong nhóm. Để đảm bảo rằng ứng dụng ngân hàng luôn có thể truy cập được,
người ta đã quyết định rằng hệ thống nên có khả năng sao lưu và chuyển đổi dự phòng dự phòng.
Các tài liệu thiết kế cấp cao và cấp thấp được kiến trúc sư rút ra.
c) Sự tham gia của người dùng vào dự án: (Nhỏ / Trung bình / Lớn)
d) Kết thúc: Tóm lại, tôi tin rằng cách tiếp cận thác nước sẽ thích hợp hơn vì các thông số kỹ thuật của
dự án rất rõ ràng và dự kiến sẽ không thay đổi. Ngoài ra, thác nước đã được sử dụng trong nhiều
ngành công nghiệp, bao gồm ngân hàng, chăm sóc sức khỏe, nhà máy điện hạt nhân và tàu con thoi.
Bởi vì các yêu cầu của hệ thống không phác thảo những thành phần nào nên được thực hiện đầu tiên,
phát triển theo giai đoạn là không cần thiết.
V-model:

a. Requirement characteristics:
 Reliability:

With all the reliability, this project are suitable for the V-model because:

 The Verification and Validation model (V-model) is the name given to this model.
The V-Shaped life cycle follows a sequential course, much like the waterfall model.
Before moving on to the next level, each one must be completed.
 The product will be tested concurrently with the development of a new version.
 Waterfall was the original inspiration for the V-model, a software development
methodology. Requirements, specifications, design, and implementation are all part
of the process, which includes a verification and validation step. This is done by unit
testing, integration testing, system testing, and finally acceptance testing, which
ensures that the requirements have been met.
  Types and number of requirements:
 In the V-model, the project team identifies the high-level and detailed
design phases of the project based on the project's needs. The requirements
get more and more specific as each level is accomplished.
 How often the requirements can change
 The V-shaped architecture is best suited for small to medium projects with
well-defined and fixed requirements. It's best to go with a V-Shaped design
if you have the necessary technological resources and expertise.
 Can the requirements be defined at an early stage
 Activities such as test planning and design take place long before code is
written. This is a time-saver. As a result, the waterfall paradigm has a lower
success rate.
b. Development team:
 Team size:
 Level of understanding of user requirements by the developers:
 Unit tests, integration tests, system tests, and acceptance tests are all
included in the V-Model. The unit and integration tests ensure that the
system's design is implemented in the code through the use of automated
testing.
 Customer expectations are met through system and acceptability testing.
Various components of the software are tested at various levels, each of
which is performed independently of the others. To begin testing a new
level, the V-model requires that the preceding level must be finished first.
c. User involvement in the project: (Small/Average/Large)
d. Conclusion:
 To summarise, I believe that the V-model is best suited to this situation, as the
criteria are well defined and unlikely to alter. Because of the limited size of the
group, each member should concentrate on a single stage at a time. Development in
stages is unnecessary because the system's requirements don't specify which parts
of the system should be deployed first.

Waterfall:

a. Requirement characteristics:
 Reliability:

With all the reliability, this project are suitable for the Waterfall because:

 Process Models were first introduced in the Waterfall Model. The term "linear-
sequential life cycle model" is also used to describe this concept. It's a breeze to
learn and master.
 Using a waterfall paradigm, each stage must have been finished in full before the
next stage can be started. Projects that are less than a year old and have no
ambiguous requirements are ideal candidates for this paradigm of software
development.
 It is only appropriate to apply this paradigm if the needs are well-known, clearly
defined, and unchanging.
 Types and number of requirements:
  The business analyst gathers the requirements and the team analyzes them
in this phase. During this stage, requirements are written down and more
explanations can be obtained.
 The requirements are documented by the Business Analysts once they have
spoken with the customer. The project team requires answers to the
following questions, which were not included in the requirements paper,
after going over and analysing the requirements.
 How often the requirements can change:
 This is due to the stringent regulations and standards that must be adhered
to.
 As a result, the requirements for these projects are well-known in advance,
and contracts stipulate precisely what must be delivered when the project is
completed.
 Design modifications can be implemented earlier in the Waterfall approach,
which is advantageous because later design changes are difficult to
implement. Easy.
 In order to make this change, there is no need for any code or
implementation. - Appropriate for projects with a tight deadline: The
Waterfall model's sequential nature lends itself nicely to projects involving
teams and organisations that thrive when given deadlines.
 Team members will be able to readily grasp and follow the timeline if it is
broken down into particular times. Furthermore, the researcher's job is
made easier by having a timeline for the entire process and by establishing a
few particular deadlines or milestones for each stage.
 Can the requirements be defined at an early stage:
 As a result of the model's rigidity, it's straightforward to keep track of the
project's progress.
 Phases are done sequentially under this model. Do not mix phases.
 For smaller projects with well-defined and well-understood needs, the
waterfall paradigm works well.
b. Development team:
 Team size:
 Level of understanding of user requirements by the developers:
 The project's high- and low-level software architecture is the responsibility
of the architect and other senior members of the team. To ensure that the
banking application is always accessible, it has been decided that the system
should have redundant backup and failover capabilities. High-level and low-
level design documents are drawn out by the architect.
c. User involvement in the project: (Small/Average/Large)
d. Conclusion:
 To summarise, I believe that a waterfall approach would be preferable because The
project's specifications are clear and not expected to alter. Additionally, waterfall
was used in a variety of industries, including banking, healthcare, nuclear power
plants, and space shuttles. Because the system's requirements do not outline which
components should be implemented first, staged development is not essential.