Group 3 - Software Engineering Assignment
Group 3 - Software Engineering Assignment
• Additional training and skills might be required Agile itself requires a lot of training and skilled use in order to
be successful. Most companies don’t understand this and so try to do everything quickly and avoid investing
any additional effort. Unfortunately, the resulting projects often fail.
• Transformation of the organization. In order to be successful, the Agile approach may also necessitate some
level of organizational restructuring. Business stakeholders must work with the development team in a spirit
of partnership and trust. This may entail removing organizational hurdles that make it difficult or impossible
to do so.
• Scalability Implementation of the Agile approach in large projects is often a complex and time-consuming
endeavor. There are several models for this (Scrum-of-Scrums, LeSS and SAFe), but none of them is an easy-
to-implement universal solution.
• Integration with project or program management. Agile is not always suitable for projects that require a
planned approach to achieve a certain level of predictability.
Iterative Model
The iterative model is a specific execution of a software development life cycle (SDLC) that spotlights on an
underlying, worked on execution, which then, at that point, continuously acquires intricacy and a more
extensive list of capabilities until the last framework is finished. The iterative cycle begins with a basic
execution of a subset of the software requirements and iteratively upgrades the advancing renditions until the
full framework is carried out. At every emphasis, plan alterations are made, and new useful capacities are
added. The fundamental thought behind this technique is to foster a framework through rehashed cycles
(iterative) and in more modest parts all at once (incremental).
The following illustration is a portrayal of the Iterative model –
Phases
• Requirements - At this stage requirements are gathered from customers and checked by analysts whether the
requirements are reasonable or not. Analysts check that will they achieve set expectations for example are they
within budget or not. Major requirements must be clearly stated and other functionalities or requested attributes can
be applied with time to the product.
•
• Design - The technical requirements are defined, the languages, data layers and services that will be used in order to
meet the analysis stage. Data Flow Diagrams, Class Diagram, State transition Diagrams are designed.
•
• Implementation - The coding process takes place here where by the current build is coded. All planning, specification
and design documents on that iteration are coded and implemented into the project.
•
• Testing - When the current build has been coded and implemented the software is then tested using different test
methods such as. The testing process is to find if there are any errors in the program that have occurred.
•
• Evaluation - Assessment of the project by the entire team and clients as well. Reviewing behaviour and validity of the
developed product. Examining the project where the project is, where it can be and what can and should change
about it. If there are any errors found then the process starts all over again.
Applications
• Necessities of the total framework are characterized and perceived.
• Significant prerequisites should be characterized; notwithstanding, a few functionalities or mentioned
improvements might advance with time.
• There is a chance to the market imperative.
• Another innovation is being utilized and is being educated by the advancement group while dealing with the
undertaking.
• Assets with required ranges of abilities are not accessible and are intended to be utilized on agreement
reason for explicit cycles.
• There are a few high-hazard elements and objectives which might change later.
Advantages
• Intrinsic Versioning: It is somewhat clear that most software development life cycles will incorporate some type of versioning,
showing the delivery phase of the product at a specific stage. Notwithstanding, the iterative model makes this considerably
simpler by guaranteeing that more current cycles are steadily further developed versions of past iterations. Also, if another
iteration in a general sense breaks a framework disastrously, a past cycle can rapidly and effectively be carried out or "rolled
back," with negligible misfortunes, a specific aid for post-release support or web applications.
• Fast Turnaround: While it might seem like each phase of the iterative cycle isn't too unique in relation to the phases of a more
customary model like the waterfall model - and accordingly the interaction will take a lot of time - the magnificence of the
iterative cycle is that each stage can adequately be thinned down into increasingly small time periods; whatever is important to
suit the necessities of the undertaking or association. While the first run-through of all stages might take some time, each
resulting iteration will be quicker and quicker, fitting that agile moniker so great, and permitting the existing pattern of each
new cycle to be managed down to only days or even hours sometimes.
• Appropriate for Agile Organizations: While a bit-by-bit process like the waterfall model might function admirably for huge
associations with many colleagues, the iterative model truly begins to sparkle when it’s in the possession of a more modest,
lither group. Especially when joined with the force of current rendition control frameworks, a full "iteration process" can
successfully be performed by various individual colleagues, from design and planning through to execution and testing, with
practically zero requirements for outside criticism or help.
• Simple Adaptability: Hinging on the centre strength of consistent, successive iterations emerging regularly, one more essential
benefit of the iterative model is the capacity to quickly adjust to the steadily changing requirements of both the project and
the impulses of the customer. Indeed, even key changes to the fundamental code structure or implementations (like a new
database framework or service execution) can ordinarily be made inside an insignificant time period and at a sensible expense,
in light of the fact that any negative changes can be perceived and returned inside a brief period of time to a past iteration.
Disadvantages
• Expensive Late-Stage Issues: While not really an issue for all projects, because of the insignificant
introductory preparation before coding and execution start, while using an iterative model, it is conceivable
that an unanticipated issue in the plan or hidden framework design will emerge late into the undertaking.
Settling this could have possibly destroying impacts on the time period and expenses of the venture in
general, requiring a lot of future iterations just to determine one issue.
• Expanded Pressure on User Engagement: Unlike the waterfall model, which stresses practically all
client/customer commitment inside the underlying phases of the venture during a short time to get down to
business period, the iterative model frequently requires client commitment all through the entirety of the
cycle. This is here and there an appalling commitment since each new cycle will probably require testing and
input from clients to appropriately assess any important changes.
• Feature Creep: Not just does the iterative model require client criticism all through the interaction, however,
this likewise innately implies the task might be dependent upon undesired feature creep, by which clients
experience the progressions in every iteration, and are leaning to continually advance new demands for
extra elements to be added to future renditions.