PROGRAM TITLE: Software Development Lifecycles

UNIT TITLE: Software Development Lifecycles

ASSIGNMENT NUMBER: Unit 9
ASSIGNMENT NAME : Software Development Lifecycles
SUBMISSION DATE: 14/06/2022
DATE RECEIVED: 18/06/2022
TUTORIAL LECTURER: Phan Son Tung
WORD COUNT: 5700

STUDENT NAME: Lê Anh Minh

STUDENT ID: BKC12089
MOBILE NUMBER: 0376697126
 Summative Feedback:

Internal verification:

Contents
Describe different software development lifecycles.......................................................................4

1. Introduction:.........................................................................................................................4

2. Description of predictive and adaptive software development models considering at

least two iterative and two sequential models...........................................................................5

2.1. Requirement Phase:.......................................................................................................5

2.2. Analysis Phase:.............................................................................................................5

2.3. Design Phase:................................................................................................................6

2.4. Development Phase:......................................................................................................6

2.5. Testing and Integration:................................................................................................6

2.6. Deployment & Maintenance Phase:..............................................................................6

3. Describe two iterative and two sequential software lifecycle models................................7

3.1. Agile Models:................................................................................................................7

3.2. V-Model........................................................................................................................8

3.3. Waterfall Model..........................................................................................................10

3.4. Prototyping Model.......................................................................................................11

3.5. Risks in Wateral Model...............................................................................................13

3.6. Risks involved in V-model..........................................................................................13

3.7. Risks involved in Prototype Model.............................................................................13

3.8. Risks involved in Agile Model....................................................................................14

3.9. Explain how risk is managed in the Spiral lifecycle model........................................14

3.10. Spiral development supports risk management in software projects in several ways

summarized in the following:.................................................................................................15

Explain the importance of a feasibility study................................................................................16

1. Introduction importance of feasibility study......................................................................16

2. Purpose of Feasibility Study:..............................................................................................18

3. Performance and efficiency:...............................................................................................18

4. Legacy system upgrade......................................................................................................19

5. Automation.........................................................................................................................19

6. Elimination of human errors...............................................................................................19

7. Describe how technical solutions can be compared............................................................19

                                                                                                                                                   
Describe different software development lifecycles
1. Introduction: 
The large insurance company predominantly operating in United Kingdom is now
offering its products and services to many of the countries in its drive to grow and become a
large international company. The system that this company is using to keep track of its customer
enquiries about information and purchase of its products and services needs to be updated to
reflect the changes in the way it operates. So, to go towards the international market this
company needs to update its old system and replace it with new system, which provides other
various services. As the customers in other countries will be using wide range of currencies to
purchase the products and the insurance company need to allow for the fluctuating currency
exchange rates in its new system. For this software development task our business consultancy
company has won contract and I was hired as systems analyst to develop new system of
insurance company. 
My Role as System Analyst 
For the development of this project, I have to work with my colleagues as part of a
development team. In past the insurance company has small development team, which solely
developed the old system so while developing this new system in-house team will also work
alongside us for better understanding of their requirements. I am going to manage the project
analysis and design stage of new system. Firstly, I am going to update the in-house team on new
methodologies of system development used to analyze systems.
2. Description of predictive and adaptive software development models considering at least two
iterative and two sequential models. 
Software Development Life Cycle:
The software development life cycle (SDLC) is an outline identifying tasks executed at
each stage in the software development procedure. SDLC is a design tracked by a development
team within the software organization.
It consists of a comprehensive plan describing how to develop, maintain and replace
specific software. The life cycle defines a methodology for improving the quality of software and
the overall development process.
The software development life cycle is also known as the software development process.
(Techopedia, 2019)
Stages of Software Development Life Cycle (SDLC):
2.1. Requirement Phase:
Requirement gathering and analysis is the most important phase in the software
development lifecycle. Business Analyst collects the requirement from the
Customer/Client as per the client’s business needs and documents the requirements in the
Business Requirement Specification (document name varies depends upon the Organization.
Some examples are Customer Requirement Specification (CRS), Business Specification (BS),
etc., and provides the same to Development Team.
2.2. Analysis Phase:
Once the requirement gathering and analysis is done the next step is to define and
document the product requirements and get them approved by the customer. This is done through
the SRS (Software Requirement Specification) document. SRS consists of all the product
requirements to be designed and developed during the project life cycle. Key people involved in
this phase are Project Manager, Business Analyst and Senior members of the Team. The
outcome of this phase is the Software Requirement Specification.
2.3. Design Phase:
It has two steps:
HLD – High-Level Design – It gives the architecture of the software product to be
developed and is done by architects and senior developers
LLD – Low-Level Design – It is done by senior developers. It describes how each and
every feature in the product should work and how every component should work. Here, only the
design will be there and not the code
 The outcome from this phase is High-Level Document and Low-Level Document which
works as an input to the next phase
2.4. Development Phase:
Developers of all levels (seniors, juniors, freshers) involved in this phase. This is the
phase where we start building the software and start writing the code for the product. The
outcome from this phase is Source Code Document (SCD) and the developed product.
2.5. Testing and Integration:
When the software is ready, it is sent to the testing department where Test team tests it
thoroughly for different defects. They either test the software manually or using automated
testing tools depends on the process defined in STLC (Software Testing Life Cycle) and ensure
that each and every component of the software works fine. Once the QA makes sure that the
software is error-free, it goes to the next stage, which is
Implementation. The outcome of this phase is the Quality Product and the Testing
Artifacts. After the successful test of the application we need to integrate the various modules
like login, signup, upload, claim, services.
2.6. Deployment & Maintenance Phase:
After successful testing, the product is delivered/deployed to the customer for their use.
Deployment is done by the Deployment/Implementation engineers. Once when the customers
start using the developed system then the actual problems will come up and needs to be solved
from time to time. Fixing the issues found by the customer comes in the maintenance phase.
100% testing is not possible – because, the way testers test the product is different from the way
customers use the product. Maintenance should be done as per SLA (Service Level Agreement)
3. Describe two iterative and two sequential software lifecycle models.
3.1. Agile Models: 
The iterative models are particular implementation of a software development lifecycle
that focuses on an initial, simplified implementation, which then progressively gains more
complexity and a broader feature set until the final system is complete. In this type of model’s
enhancements can be recognized quickly with implementation throughout each iteration. The
two iterative models which I am going to describe are prototype and agile models. 
Agile model   Please add sprint, scum. Standup meeting, client’s feedback, backlog,
sprint backlog. Please include the manifesto of agile.
“Agile SDLC model is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of working software
product. Agile Methods break the product into small incremental builds. These builds are
provided in iterations.” (n.d, 2018) In this model every project is handled differently and existing
methods are tailored to best suit requirements of project. All tasks are divided in small time
frames for delivering specific features in release. It gives priorities to working software and
customer collaboration over comprehensive documentation and contract negotiation. This model
also allows proper response to change than following the project plan and every iteration
includes cross functional team working simultaneously. 
Agile model is iterative and team-based way to development. This model gives
importance in rapid delivery of system in complete functional components. All time is time
boxed in phases known as sprints rather than creating tasks and schedules for system
development. While starting each sprint has defined duration although time may vary according
to project and also the running list of deliveries. Sometime if planned work for sprint cannot be
completed then work is reprioritized again and information is used for further sprint planning.
When the work is completed then it is reviewed and evaluated by team and customers. This
model relies in high level of customer involvement throughout development process and it is
more especially during reviewing the system. 

Advantages

It is very easy, realistic approach that provides flexibility to developers. And teamwork
promotes and cross training.

It provides continuous attention to technical excellence and good design.

Minimum rules and documentation can be easily employed.

 It is best suitable for environment where requirements may change during development
process.
Resource requirements are minimum and only little planning is required.

Disadvantages

There will be high individual dependency as minimum documentation is generated.

As there are strict delivery management adjustments can be dictated to meet deadlines.

It is very difficult to implement this model without overall plan, an agile leader and agile
project manager.

If customer representative is not clear about the outcome of project then team can easily
get off the track.
During the development transfer or recruiting of new member in project will be quite
challenging due to lack of documentation.

3.2. V-Model
V-Model is mostly known as the validation and verification software development
process model (The Vee Model), and It is one of the most know software development
methodology. Although it is considered as an improvement to the waterfall model and it has
some similarities as the process also based on sequential steps moving down in a linear way, it
differs from the waterfall model as the steps move upwards after the coding phase to form the
typical V shape. This V shape demonstrates the relationships between each phase of the
development life cycle and its associated phase of testing.
V-Model Model Advantages

 Simple and easy to use

 Each phase has specific deliverables.
 Higher chance of success over the waterfall model due to the development of test
plans early on during the life cycle.
 Works well for where requirements are easily understood.
 V-Model Improves the quality and reliability of the software.
 It reduces the amount of re-work because of the early detection of defects and issues.
 It provides better management for project risks.
 Verification and validation of the product in the early stages of product development
ensures better quality.
 The V-Model concept can be combined with other models, for example, the iterative
and agile models.
V-Model Model Disadvantages

 Very inflexible, like the waterfall model.

 Adjusting scope is difficult and expensive.
 The software is developed during the implementation phase, so no early prototypes of
the software are produced.
 The model doesn’t provide a clear path for problems found during testing phases.
  Moreover, It is costly and required more time, in addition to a detailed plan

3.3. Waterfall Model 

It is mostly known as the traditional software development process model, widely used
until now, and the most popular SDLC model and the one you should avoid to use. Moreover, it
was the first introduced presentation of the software lifecycle.

The Waterfall Model is a linear sequential flow. In which progress is seen as flowing
steadily downwards (like a waterfall) through the phases of software implementation. This
means that any phase in the development process begins only if the previous phase is complete.
The waterfall approach does not define the process to go back to the previous phase to handle
changes in requirement.

Waterfall Model Phases

Waterfall Model contains the main phases similarly to other process models, you can
read this article for more information about phases definitions.
Waterfall Model Advantages

 It is very easy to explain to the business users and explain the output of each phase.
 Structures approach.
 Stages and activities are well defined.
 It is easier for project managers to plan, schedule the project, utilize the resources, and
define the milestones easily.
 Validation and verification at each phase ensure early detection of
errors/misunderstanding at the same phase.
 Each phase has specific deliverables.
Waterfall Model Disadvantages

 It takes the full lifecycle to deliver a workable solution to the customer.

 It is very difficult to go back to any phase after it finished.
 It assumes that the requirements of a system can be frozen without any changes or
enhancements.
 A little flexibility and adjusting scope is difficult and expensive.
 It requires more time for the detailed plan upfront of the project, as the requirements
are clear and frozen and it should be visible to have the detailed plan delivered to the
customer.
  It delays the testing phase which can discover a lot of issues in requirements, design,
and implementation as well.
This is the earliest model of software development and is only applicable when the
requirements are very well known, clear and fixed. If there is no proper documentation for user
requirements then it can’t be used. This model further can be used when the product definition is
stable and technology is understood. Only after proper evaluation and reviewing each stage
developer should move to the next step so proper documentation of user requirement should be
done. It is also applicable where there is no chance of customer collaboration in the project and
whole task is done in contract negotiation. This model can be used in projects where there are no
ambiguous requirements. Waterfall model is also suitable for projects that transfer from one
platform to another platform i.e. all the requirements remain the same and there is only change in
system environment or the programming language. This is best suited for the small projects
rather than complex large projects which take more time.
3.4. Prototyping Model
Software prototyping is the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. It is an activity that can occur
in software development and is comparable to prototyping as known from other fields, such
as mechanical engineering or manufacturing.

A prototype typically simulates only a few aspects of, and may be completely different
from, the final product

Advantage

There are many advantages to using prototyping in software development – some

tangible, some abstract

Reduced time and costs: Prototyping can improve the quality of requirements and
specifications provided to developers. Because changes cost exponentially more to implement as
they are detected later in development, the early determination of what the user really wants can
result in faster and less expensive software.

Improved and increased user involvement: Prototyping requires user involvement and
allows them to see and interact with a prototype allowing them to provide better and more
complete feedback and specifications.[6] The presence of the prototype being examined by the
user prevents many misunderstandings and miscommunications that occur when each side
believe the other understands what they said. Since users know the problem domain better than
anyone on the development team does, increased interaction can result in a final product that has
greater tangible and intangible quality. The final product is more likely to satisfy the user's desire
for look, feel and performance.

Disadvantage

Using, or perhaps misusing, prototyping can also have disadvantages.

Insufficient analysis: The focus on a limited prototype can distract developers from
properly analyzing the complete project. This can lead to overlooking better solutions,
preparation of incomplete specifications or the conversion of limited prototypes into poorly
engineered final projects that are hard to maintain. Further, since a prototype is limited in
functionality it may not scale well if the prototype is used as the basis of a final deliverable,
which may not be noticed if developers are too focused on building a prototype as a model.

User confusion of prototype and finished system: Users can begin to think that a
prototype, intended to be thrown away, is actually a final system that merely needs to be finished
or polished. (They are, for example, often unaware of the effort needed to add error-checking
and security features which a prototype may not have.) This can lead them to expect the
prototype to accurately model the performance of the final system when this is not the intent of
the developers. Users can also become attached to features that were included in a prototype for
consideration and then removed from the specification for a final system. If users are able to
require all proposed features be included in the final system this can lead to conflict.

Developer misunderstanding of user objectives: Developers may assume that users share
their objectives (e.g. to deliver core functionality on time and within budget), without
understanding wider commercial issues. For example, user representatives attending Enterprise
software (e.g. PeopleSoft) events may have seen demonstrations of "transaction auditing" (where
changes are logged and displayed in a difference grid view) without being told that this feature
demands additional coding and often requires more hardware to handle extra database accesses.
Users might believe they can demand auditing on every field, whereas developers might think
this is feature creep because they have made assumptions about the extent of user requirements.
If the developer has committed delivery before the user requirements were reviewed, developers
are between a rock and a hard place, particularly if user management derives some advantage
from their failure to implement requirements.

Developer attachment to prototype: Developers can also become attached to prototypes

they have spent a great deal of effort producing; this can lead to problems, such as attempting to
convert a limited prototype into a final system when it does not have an appropriate underlying
architecture. (This may suggest that throwaway prototyping, rather than evolutionary
prototyping, should be used.)

Excessive development time of the prototype: A key property to prototyping is the fact
that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may
try to develop a prototype that is too complex. When the prototype is thrown away the precisely
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.

3.5. Risks in Wateral Model

“As there is very less customer interactions involved in software development and
product can only be demoed once it is ready therefore once the software is developed and if any
failure once then cost of fixing such issues are very high and we have to update everywhere from
document till the logic. Another risk is that if the documentation of software development isn’t
done well then there is high chance of getting off the track while developing software. There is
always lack of project suitability using this model where requirements are at a moderate to high
risk of changing. There is high chance of project failure if we use this model for complex and
object-oriented projects.
3.6. Risks involved in V-model 
As, it is too simple to accurately reflect the software development process, and can lead
managers into a false sense of security. The V-Model reflects a project management view of
software development and fits the needs of project managers, accountants and lawyers rather
than software developers or users. Although it is easily understood by novices, that early
understanding is useful only if the novice goes on to acquire adeeper understanding of the
development process and how the V-Model must be adapted and extended in practice. If
practitioners persist with their naive view of the VModel they will have great difficulty applying
it successfully.  It is inflexible and encourages a rigid and linear view of software development
and has no inherent ability to respond to change.

3.7. Risks involved in Prototype Model

Although using prototyping model decreases the probability of software development

project failure apart from rewards this model has its own risks. The biggest risk is that anyone
who is interested in the project after facing a working prototype will decide that the final product
is almost ready or not. Another risk involved using prototype model is that after seeing the early
prototype end users demand delivery of actual system and even if he is unsatisfied with the
 initial built prototype, he may lose interest in the project. While using this model in software
development process, without proper management iterative process of prototype refinement can
take long durations and while developer hurry to build prototype it may end up to sub-optimal
solutions. Practically, using this model might increase the complexity of the system as scope of
the system may expand beyond the initial plans on software development. Various risks can be
encountered as this model leads to implementing and then repairing the way of creating
software. 

3.8. Risks involved in Agile Model 

There are various risks involved in the agile model and while developing the software we
have to be aware about those risks before starting our project. Among those various risks the
very first common risk is lacking details in task descriptions. We have to make sure that all
details are present and clear for the team so they know exactly what they are creating and the
best way to write these out are in the form of user stories or technical requirements. Another risk
usually encountered while going through agile model is priorities or directions change.
Sometimes the priorities of the project changes and thus features that were not originally planned
take top priority over the others.

When this happens, it’s important to make sure the clients know about the effect of those
changes on the developing system and even also the timeline and budget of project as mentioned
in earlier meetings. Another risk which many companies faces while adapting agile model in
their software development process is lack of documentation which leads to misunderstanding
among the developers. Because of poor documentation in this model when the current
programmer or any other member of development team leaves then it will be very difficult for
the new recruiters to get adapted with development scenario as there will be less documentation
and he won’t be able to grab the speed with other members. If the customer representative isn’t
clear about the outcome of project then team can easily get off the track so this risk should not be
underestimated while developing team and client representative should be well known about the
features that clients wants to get in system. 

3.9. Explain how risk is managed in the Spiral lifecycle model.

Spiral model was proposed as a risk driven software development process model by
Boehm in 1988 wherein the development process is guided by involved risks. This model aims
to identify and evaluate the software project risks and also helps to reduce those risks. In this
model the major sources of risk despite of its risk driven nature is due to high reliance on human
factor and detailed risk management process. According to Boehm, almost the 25% time in this
 model is taken in risk analysis and it is mostly designed to known risk in the project. It doesn’t
only provide the flexibility in project but also helps us to know about the upcoming risks.

3.10. Spiral development supports risk management in software projects in several ways

summarized in the following:
 The initial risk analysis that acts as a look-ahead step and aims at:
o Identifying most risks threaten the project.
o Classifying risks into user interface risks and development risks
o Evaluate these risks to decide upon the risks to handle through each cycle.
Moreover, this classification helps developers in implementing risk resolution techniques such as
prototyping and benchmarking.
 The evolutionary prototyping spirals that aim at resolving performance and user
interface related risks. These spirals help in reducing major risks before proceeding into the
development process.
 The risk analysis stage at each cycle that precedes each phase of the waterfall
phases in purpose of:
o Resolving program development and interface control risks inherent from the start
of the project.
o Evaluating and resolving the new risks that might arise after changing any of the
objectives, alternatives, or constraints at the beginning of the cycle.
 The iterative feature of the spiral which allows the development process to go
back to the first quadrant at any point in progress which allows:
 o Objectives, alternatives and constraints to change as more attractive alternatives
exist.
o New technology to be incorporated easily during the development process.
o The maximum optimization of project resources usage.
o To deal with poorly done activities in the earlier phases.
 The review conducted at the end of each cycle with main stakeholders as a
decision point to avoid the lack of commitment risks during the next cycle.
 Time and cost overrun risks are best managed using spiral development due to the
risk analysis stage conducted at each cycle. In this stage, the cost and time required for each
cycle are analyzed in advance to give a clear picture about the critical state of the project.
This helps the project manager and the developers get more control over these risks.
 Risks related to the increased complexity of the project are also managed using
spiral.
This is achieved by the partitioning activity conducted at the planning phase.
o Decomposing the project into portions to be developed in parallel spirals
obviously reduces time contention related risks, since more work could be achieved during the
same interval.
Major Sources of Risk in the Spiral Model Despite its risk driven nature, spiral has its
own sources of risks which are summarized in the following:
 High reliance on the human factor
o All the activities related to identifying, analyzing, and resolving risks rely on the
experience of developers and their abilities in identifying and managing risks. If these abilities
are unavailable, major risks might remain hidden for several lifecycles and discovered late when
it matured into real problems. At that time, the cost of rework to recover from these risks
becomes very high.
 Detailed risk management process
o Cost and schedule risks might increase using spiral due to its iterative feature,
especially for low risk projects wherein risk assessment is not required to be at this level of
granularity.
Explain the importance of a feasibility study
1. Introduction importance of feasibility study
“A feasibility study is an analysis used in measuring the ability and likelihood
to   complete a project successfully including all relevant factors. It must account for factors that
affect it such as economic, technological, legal and scheduling factors. The feasibility study
helps to “frame” and “flesh-out” specific business scenarios so they can be studied in-depth.
Project managers use feasibility studies to determine potential positive and negative outcomes of
a project before investing a considerable amount of time and money into it.” (Don Hofstrand,
October, 2009) It tests the viability of opinion, a project or even new business. It is the
preliminary study undertaken before the real work of project starts to ascertain the likelihood of
the project’s success.

The main purpose of feasibility study is to emphasize the problems which could occur if
one pursues project and determines if, after considering all significant factors, the project is a
good idea.

Importance of Feasibility study

Marketing study : Marketing research is conducted to evaluate whether the project is

suited for the current and future organizational culture. In this process, the consultants will look
in finding data on overall impact on business structure, employees an organization. Sale
projection is also one of the vital parts of market research. The main objective of marketing
research is to identify the target consumers, know the demand of the consumers, understand the
market characteristics and evaluate the factors that provide a great impact on the buying
decisions.

Financial study : Financial planning is very important to handle the different operations

of the organization within the budget limits. In financial research, the researchers cover the
assessment of total capital requirements, sales and prices, break even outputs, amount of sales
required to attain profit in the business. It helps entrepreneurs to get an idea about how much
money is required for handling a business project successfully.

Management study : Management research is conducted to determine the overall

resources required for the successful completion of the project. Some projects, like
manufacturing will require more physical resource while some IT project requires lots of human
resources. Schedule study Schedule feasibility is conducted to determine how much time and
resources are required to finish the project on time. As the feasibility research plays a vital role
in the successful completion of the project. You need to hire professional management
consulting firms in order to get the right and effective report. Gulf Resources is one of the top
business management consulting firm that conduct a Feasibility study in UAE for clients from
various fields like healthcare, food, engineering, cosmetic and body care shop
2. Purpose of Feasibility Study:
Please write these things in bullets.
The significance of feasibility study is based on organizational desire to “get it right”
before implementing resources, budget and time in project. It might uncover new ideas that
could completely change a project’s scope. It is always beneficial to make those determinations
before rather to jump in and starting the project that won’t work. The outcome of feasibility
study gives us and our stakeholders a clear picture of the proposed project and is always
beneficial
Another purpose for feasibility report is to explore the different markets where a target
audience might be located Recommendation: 
In this way doing feasibility study always helps us while doing the project. The main
purpose of feasibility report is to find our if it is worth doing and if the report shows negative
result then it offers one chance to get it right before we invest our time and money in project. It
provides us the various potential risks in that project so that we can mitigate them in initial
before they turn into huge problem. Not only it tells us to remove the project ideas but also
identifies the reasons not to proceed project so that in future we can be aware about those reasons
before. While creating insurance company software it helped our group decide to expand
existing services, build or remodel facilities, change methods of operation, add new products etc.
In this way using the feasibility study while doing our project for insurance company we are able
to understand about our project so I also recommend others to use this while starting their
project. 
Designing and implementing the solution of the technical problems like financial
problem, machinery problems etc. during the lifecycle of the project means Technical solution.  
I am going to show the technical solution of cell phone and landlines and compared with
the following key drives: 
 Performance and efficiency 
 Legacy systems upgrade 
 Automation 
 Elimination of human errors 
 Budget/ economic 
3. Performance and efficiency: 
Cell phones are mobile which means portable and can be taken from one place to another
and are operational anywhere the user can get a signal from a wireless network whereas landline
phones are not mobile and customers can only use it in a single location where there is a
presence of wired connection to telephone network. A cell phone can be very useful during the
 emergency that arise when you’re away from home. Cell phones have the capacity and advanced
technology. Cell phones can also give you a chance to take live pictures or videos camera
whereas landline cannot. Cell phones are more fashionable and comfortable than landline. 
4. Legacy system upgrade 
One of the clearest benefits you will see is an immediate drop in both service charges as
well as call costs. It helps in the business continuity and employees still have access to core
communication systems like phones, sending and receiving messages, video-clips conversation
etc. it also make able to add features to your lines for easier conferencing and communication. 
5. Automation  
The both system typically play a message, then ask the caller to either press a button or
speak a response. Depending on the caller’s input the automated phone system may play some
information, route the caller to another prompt or connect the caller with a human operator.   
6. Elimination of human errors
Human error is an imbalance between what the situations requires, what the person
interacts and what he/she does. It happens when people plan to do the right thing but with the
wrong outcome.
Cell phone have GPS technology that can find your exact location or where you trying to
go.  
Budget / economic 
The similarity of landline and cell phone is the fact that they are both used for
communication. The most common reason to choose a cell phone is that in most areas, the cost
of a cell phone plan is lower than the cost of a landline, especially when you count the cost of a
long distance calling plan. Nowadays, we see many people on the streets with their cell phones,
as many people know that it’s easier and cheaper. 
7. Describe how technical solutions can be compared

Company need Solution Cost Other suppliers

Works in the cloud. Alibaba Icloud : 1000$/year Amazon Icloud

Mass storage of data.
Cost : 1500$/year
Absolute security
Maintenance can be
done at any time
Good employee Ecount : 1200$/year Base HRM+
monitoring software.
Easy to use Diverse Cost : 2000$/year
menu, easy to use!
Human resource data,
More than 60,000
modeling enterprise
businesses in all
organizational
fields trust ECOUNT
structure. Managing,
monitoring
fluctuations and
allocating salary
funds to each
department.

Email Server EMAIL PRO #1 20,400 VND EMAIL PRO #2

Capacity: 2 GB x 36 months 48,500 VND

Email Address : 2 VND 24,000 x 12 x 36 months

months
Email forwarder : 2 57,000 VND x 12
21,600 VND x 24 months
Mail list : 1
months
51,300 VND x 24
Park Domains
months

Capacity: 6 GB

Email Address : 6

Email forwarder : 6

Mail list : 2

Park Domains: 0

Firewall Firewall FG-600F- 2000$ Cisco Meraki MX67

BDL-950-12 Security & SD-WAN
FortiGate 24x7 UTM Integrated Firewall
Protection 1 Year
Cisco Meraki MX67
Bundle The FG-
is a firewall that
600F-BDL-950-12 is
 a Fortigate FG-600F integrates many
firewall with a built- versatile features
in bundle of 24x7 such as security,
UTM Protection with switching, SD-WAN.
advanced security MX67's firewall
and all-time customer throughput is up to
support services: 600 Mbps and site-to-
FortiCare, FortiGuard site VPN throughput
App Control Service, is up to 300 Mbps,
IPS Service, supporting up to 50
Advanced Malware users. The device
Protection (AMP) - gives businesses a
Antivirus, Mobile convenient and
Malware, Botnet, economical all-in-one
CDR, Virus Outbreak network solution,
Protection and employees can share
FortiSandbox Cloud resources between
Service, Web branch offices easily
Filtering Service, and securely.
Antispam Service.
Cost : 5000$
These services are
valid for 1 year.

Router Archer AX1500 1000$ Archer C64

AX1500 . Wi-Fi 6 Router WiFi MU-

Router MIMO AC1200

1201 Mbps + 300 867 Mbps + 400

Mbps Mbps

5 Gigabit ports 5 Cổng Gigabit

CPU Triple Core 1.5 Beamforming

GHz
MU-MIMO

Cost : 2000$
Referrence :

https://desklib.com/2021/7/1/software-development-life-cycle-sdlc-assignment/?
fbclid=IwAR32StHaxxmlhWJ_oS-vP2jeuebLML1Lu69x5cmG8PlYexan2WNlBMIw4g4

https://signup.base.vn/b118-hrm-plus-cc/?
utm_source=coc_coc&utm_medium=conversion&utm_campaign=b118-hrm-ns-
cc&utm_content=b118-hrm-ns-cc&utm_term=ph%E1%BA%A7n%20m%E1%BB%81m
%20doanh%20nghi%E1%BB
%87p&md=_05be50vdanX6qmsEHAREeliJjBybQaLpCmWke22GfHE5dC8NQZ2Xc9NtWBJ
Akb8pUcNys401mD8N2jJyuSDQBRxXMH8G1hW4BBQx7d*Ko9areBxMPPSI7azhHu5IWdc
ZsNfs.