Developing Systems with Iterative Prototyping Methodology Project

This project explores the iterative prototyping methodology as a system development life cycle, particularly suitable for AI projects where requirements are expected to evolve. The project outlines the methodology's steps, including requirements gathering, analysis, design, user testing, implementation, integration, deployment, and maintenance. It highlights the advantages, such as early risk identification and easy testing, and disadvantages, like potential system architecture constraints. The project emphasizes the importance of a close developer-customer relationship and the use of prototypes for feedback. A Gantt chart provides a timeline for the project's tasks. The document also provides references to relevant research papers. The iterative approach allows for continuous improvement and adaptability, making it ideal for dynamic project environments. The JavaScript language is suggested for the project.

Methodology
Iterative Prototyping
The system development life cycle to be used is the iterative Prototyping methodology. This was
arrived at after consideration of the requirements specification, which are understood and
predicted to evolve with time. The process allows the developer to start with a limited part of the
requirements and the iteration design gives room to return and add to the requirements to expand
the abilities repeatedly until the system is fully developed, and can be implemented and later
deployed(Morell, 2018).
The idea is to deliver small tested features for review with the customer, meaning a continuous
improvement in small discrete parts. In simple terms, each iteration can be modified according to
new functionalities that are developed. The methodology is versatile enough, such that more than
one iteration can take place in the cycle at one given time (Choetkiertikul et al., 2018) . The
frequent, rigorous testing of each version are vital in delivering quality prototypes, making it an
ideal methodology for successful projects
Suitable projects for the method.
The methodology works best on projects of the following type:
• The essential requirements are established and analyzed, but more requirements are expected
to be added and evolve to suit the client need.
• The timeline to deliver is a constraint
• Clear requirements are well defined for a start
• The technology being used is expected to develop
• New technology is being learned by the developer
• The goals of the project are expected to change (moving target)
• The budget is limited
The advantages and disadvantages of the methodology.
Advantages

• Risks are identified and dealt with early enough, during iterations and testing.
• Testing is easy as it is done in the small modules.
• The progress of the development can be easily measured
• The lifecycle produces functional prototypes that indicate potential defects
• The development team coordinates easily
• More resources and emphasis is put on development and design rather than on
documentation.
• It is easier to incorporate ideas on the go
• It is cheaper to deal with changes in goals and scope
• The project is easily managed using milestones
• The development time is significantly reduced
• Each iteration produces an operational prototype for further evaluation
• The success rate is very high as compared to other methodologies
• The client gives feedback according to a presentable and working prototype
• The return on investment (ROI) is quick
Disadvantages
Each methodology has its limitations, but the iterative design has relatively few limitations as
compared to other methods (Dessai and Kamat, 2012).
• Lack of full requirements may lead to a constraint in the system architecture and
infrastructure
• Might need more resources to achieve the desired functionality successfully
• The successful cycles are rigid
• Professional project management may be required
• The risk analysis requires highly skilled and experienced staff
• The project duration is difficult to establish accurately and can only be estimated

When developing an application, or software, most methodologies employ a closer relationship
between the developer or the developing team and the customer. When this happens, in most times,
there occurs a trade-off between the system functionality, time and time factor (Fulbright, 2013),
leading to a pullback of one of the elements, which are essential.
The iterative methodology works best to collaborate and put more emphasis on the crucial factors and
implementing them effectively, which handles risks more cheaply and efficiently and saves the project from
stalling (Ramsin and Paige, 2010). Before full launch, each iteration and prototype passes through rigorous tests,
from the storyboards, wireframes and other initial stages, to front-end and back-end designs and the final stages of
the user testing. The methodology furthermore allows the developer to be reactive to possible and emerging risks
and be proactive too (Managing Iterative Software Development Projects, 2007).
Below is a diagramatic representation of the model.

3RD ITERATION Nth
1ST ITERATION
2ND ITERATION
The Iterative Prototype Methodology.
Requirements
Task ID 1
Analysis
Task ID 2
Design
Task ID 3
Testing
Task ID 4
Implementation
Task ID 5
(Prototype)
Review
Task ID 6
Design
Testing
Implementation
Review
Design
Testing
Implementation
Integration
Task ID 7
Deployment
Task ID 8
Maintenance
Task ID 9

1. Requirements
This can also be looked at as the objectives of the system. The requirements are established from
the client and even after answering some vital questions, like what is the primary function of the
application? Who is the audience targeted? What problem is the application supposed to address?
(Ramsin and Paige, 2010).
The requirements provide an understanding of about the proposed system. This establishes the
main essential requirements, at the best level of knowledge for a start, that is expected to increase
or/and evolve with time, the scope of the system and the possible integration or relationship with
existing external systems (Greco, 2016).
Case modeling can be used to identify the products beforehand like the system specification. The
requirements will then be classified and prioritization allocated (Ramsin and Paige, 2010). They
can then be enlisted in a vision document or a system charter for easier reference.
Although the requirements are expected to fluctuate and evolve, the developer should put as
many elements as possible into account and should not choose to ignore some with the idea of
including them during the iterations (Morell, 2018). This can lead to problems in the system
foundation, infrastructure and system structure in the later stages of development and might be
very expensive to incorporate the requirements at later stages(Greco, 2016)
2. Analysis
An excellent analysis of the requirements is vital for a successful project. The investigation is
conducted by the developer to establish the scalability and feasibility of the project. The
developer needs to know what’s possible at what stage of development. The requirements have
to be categorized and classified according to their ease of achievement (Ramsin and Paige,
2010). The analysis also gives the developer an insight on the best technology to achieve full
functionality.
Greater Attention is given to the difficult requirements, and risk analysis is done to ensure the
project does not fail or stall (Choetkiertikul et al., 2018). The developer starts planning as early
as possible on how to achieve full functionality. This is important since it gives an overview of
the project when also paving the way for better internalization and understanding of the
requirements.

3. Design
The design phase consists of many activities which shape the systems outlay. Whether working
individually, which is normally unusual or in a team, storyboards and wireframes can be very
useful. This can be done as sketches, which are visual presentations of the primary user flows
and functionalities (Ramsin and Paige, 2010).
These sketches act as the first prototype although non-functional. This is important to get the
team to understand and internalize the goal of the project and the expected functionalities. Some
additional requirements are also incorporated if need be (Choetkiertikul et al., 2018). The team
then decides on the approach and starts working on the project until the first functional prototype
is out, in the first iteration cycle. The preferred development language in this project is
JavaScript.
4. User-Testing
This is the most critical cycle in system development that ensures production of a sound system.
This helps in identifying possible problems in functionality and reveal some features which
might have been omitted. This also ensures the budget is adhered to and kept at controlled rates
(Choetkiertikul et al., 2018).
There are many ways to conduct testing. User testing software can be used to produce reports on
the system (Morell, 2018). The customer can also be issued the prototype and allowed to interact
with it for some time to assess their satisfaction, which is the most preferred in this project,
coupled up with the A/B tests which issue the developer with extensive user feedback (Ramsin
and Paige, 2010).
Rigorous testing at early stages and the subsequent steps is crucial as it can cut costs on the
budget. Testing on the code is also another way of ensuring quality functionality.
5. Implementation

The system iteration is then developed inclusive of the evolved and additional requirements. The
developer reviews the code using the user feedback received from the testing and implements the
changes and extra functionalities to suit the user requirements (Ramsin and Paige, 2010).
Individual modules are also tested and modified or updated accordingly.
The approved modules will be further tested to satisfaction, and the incomplete modules are
redone to full functionality.
6. Integration, Deployment and Maintenance
These are the last stages of development. In this iteration, the successful modules are integrated
into a fully operational system version. The system is tested according to the specification and
requirements (Dessai and Kamat, 2012).
The successful, operational and fully functional version is delivered to the client.

Blueprint
The project schedule is as follows:
TIME
( w
eeks)
TASK
ID
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1
2
3
4
5
6
7
8
9
The Gantt chart
 The Task ID is as indicated in the Iterative model diagram and the time is in weeks.

References
1. Choetkiertikul, M., Dam, H., Tran, T., Ghose, A. and Grundy, J. (2018). Predicting Delivery
Capability in Iterative Software Development. IEEE Transactions on Software Engineering,
44(6), pp.551-573.
2. Dessai, K. and Kamat, M. (2012). Improving Learning Outcomes Through Iterative
Teaching/Learning Methodology. SSRN Electronic Journal.
3. Fulbright, R. (2013). Incorporating Innovation into Iterative Software Development Using
the Inventive Problem Solving Methodology. International Journal of Innovation Science,
5(4), pp.203-212.
4. Greco, D. (2016). Safety, Explanation, Iteration. Philosophical Issues, 26(1), pp.187-208.
5. Managing Iterative Software Development Projects. (2007). Kybernetes, 36(1).
6. Morell, J. (2018). Systematic iteration between model and methodology: A proposed
approach to evaluating unintended consequences. Evaluation and Program Planning, 68,
pp.243-252.
7. Ramsin, R. and Paige, R. (2010). Iterative criteria-based approach to engineering the
requirements of software development methodologies. IET Software, 4(2), p.91.