CA FINAL ISCA | CH-5 | ADIS | INCREMENTAL MODEL | MNEMONICS


CA FINAL ISCA
CHAPTER 5

A D I S (Acquisition, Development & Implementation of Information systems)




INCREMENTAL MODEL


The Incremental model is a method of software development where the model is designed, implemented and tested incrementally (a little more IS added each time) until the product is finished. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.

Features:


  • A series of mini-waterfalls are performed, where all phases of the waterfall development model are completed for a small part of the system, before proceeding to the next increment.
  • Overall requirements are defined before proceeding to evolutionary, mini - Waterfall development of individual increments of the system.
  • The initial software concept, requirement analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final prototype (i.e. Working system).
Since features/characteristics are usually of 3-4 points there will be no Mnemonics for them.

MNEMONICS STORY (in हिन्दी) (For Strengths & Weakness)

If you haven't watched the Mnemonic video where the techniques are explained then watch it here.
DO watch the video to understand the linkage.

[ CLICK TO WATCH THE VIDEO]

Incremental Model मे हम T-20 match खेलेंगे।


  • T-20: टी-20 matches मे previous experience बहुत काम आता है। (pitchli knowledge आगे use मे लाते है।)
  • INDIA: India मैच मे gradually रन बना के अपनी strategy को implement करती है। 
  • PAKISTAN: पाकिस्तान का India के against हर project मे status इतना खराब है कि इसके concrete evidence है। {Cricket history देख लो}


  • CAPTAIN: Captian of a team helps to mitigate Integration & Architectural risks {Captain टीम की help करता है सबको integrate करके जिससे risks कम होते है। }

  • MUMBAI GROUND: मुंबई का flexible है। उस ground पे Hockey, football हर मैच हो सकता है इसलिए वो less costly है। 


  • UMPIRE: Umpire का decision rigid होता है। {एक बार कह दिया OUT तो मतलब आउट [नो DRS]}


  • TOSS: Toss के time teams का एक दूसरे के साथ Interface होता है। 


  • BATTING: Batting करके match (system) से related सारी problems solve हो जाती है। [बस Batting करो और दूसरी teams के लिए problem बनो]


  • HIGHEST RUN: India ने highest run बना के match ना जीत पाने वाली difficult situation को Push कर दिया। {Match जीत गए}

Now Mnemonics will be shown linked to the Actual Strengths & Weakness as per Module.
Check it out!


STRENGTHS:


  • Potential exists for exploiting knowledge gained in an early increment as later increments are developed: T-20 MATCH = टी-20 matches मे previous experience बहुत काम आता है। 


  • Moderate control is maintained over the life of the project through the use of written documentation and the formal review and approval/signoff by the user and information technology management at designated major milestones.


  • Stakeholders can be given concrete evidence of project status throughout the life cycle: PAKISTAN = पाकिस्तान का India के against हर project मे status इतना खराब है कि इसके concrete evidence है।


  • It is more flexible and less costly to change scope and requirements: MUMBAI GROUND = मुंबई का flexible है। उस ground पे Hockey, football हर मैच हो सकता है इसलिए वो less costly है। 


  • It helps to mitigate integration and architectural risks earlier in the project: CAPTAIN = {Captain टीम की help करता है सबको integrate करके जिससे risks कम होते है। }


  • It allows the delivery of a series of implementations that are gradually more complete and can go into production more quickly as incremental releases.


  • Gradual implementation provides the ability to monitor the effect of incremental changes, isolated issues and make adjustments before the organization is negatively impacted: INDIA = India मैच मे gradually रन बना के अपनी strategy को implement करती है।


WEAKNESS:


  • When utilizing a series of mini-waterfalls for a small part of the system before moving onto the next increment, there IS usually a lack of overall consideration of the business problem and technical requirements for the overall system.


  • Each phase of an iteration is rigid and do not overlap each other: UMPIRE = Umpire का decision rigid होता है। {एक बार कह दिया OUT तो मतलब आउट [नो DRS]}


  • Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle: BATTING = Batting करके match (system) से related सारी problems solve हो जाती है।


  • Since some modules will be completed much earlier than others, well-defined interfaces are required: TOSS = Toss के time teams का एक दूसरे के साथ Interface होता है।



  • It is difficult to demonstrate early success to management: PUSH DIFFICULT PROBLEM = India ने highest run बना के match ना जीत पाने वाली difficult situation को Push कर दिया। i.e difficult to demonstrate early success 

YouTube: Video coming soon.

Share:

1 comments