1 / 10

CAN YOU ASSEMBLE A “CUSTOMISED” TRAIN IN JUST A FEW HOURS WITH A FEW SKILLED WORKERS?

Discover how the modular approach used in railways can be applied to software development, allowing for customization, connectivity, flexibility, and easier management of code units. Learn about the benefits and examples of this approach.

sonyakim
Télécharger la présentation

CAN YOU ASSEMBLE A “CUSTOMISED” TRAIN IN JUST A FEW HOURS WITH A FEW SKILLED WORKERS?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IF RAILWAYS CAN DO IT EVERYDAY, WHY CAN'T SOFTWARE DEVELOPERS? CAN YOU ASSEMBLEA “CUSTOMISED” TRAININ JUST A FEW HOURSWITH A FEW SKILLED WORKERS?

  2. How do we apply it to Software Development? Railways can do it because ofThe “Modular” Approach

  3. THE “MODULAR” APPROACH • Build individual, self-contained carriages. • Enable connectivity across carriages. • Place & move the carriages on a flexible, common rail. • .

  4. THE “MODULAR” APPROACHFOR SOFTWARE • Build individual, self-contained carriages. • Identify individual output elements, action elements, operations & processes. • Find commonalities across them. • Decide optimum number of code-units of optimal size. • Make each code-unit “self-contained”.

  5. Examples of individual, self-contained carriages. • All screens have common items like textboxes, labels, listboxes, etc. • Can we write a common code which will read screen definition & generate screen dynamically? • Many times, we need actions like “Show orders of chosen customer” or “Show outlets in current area”. • Can we write common code which will handle all such “Show X for chosen Y” requests ? • A common routine to save ANY entry into ANY table? • And more ambitious – can we accommodate ALL types of transactions in a single database table?

  6. THE “MODULAR” APPROACHFOR SOFTWARE • Enable connectivity across carriages. • Make each code-unit “easy to connect”, by standardising connections. • Make error-detection simple, visible & mistake-proof. • Provide “auditable” log.

  7. THE “MODULAR” APPROACHFOR SOFTWARE • Place & move the carriages on a flexible, common rail. • Add a process to connect the code-units, as per need. • This process should be able to add, delete or bypass any code-unit, as per need. • Keep process definition separate from the code-units.

  8. Example of connectivity across carriages. A B C D E • Visualise a process having 5 steps, in which step “C” is exercising credit control. Conventional approaches Modular Approach A B C D E A Monolithic OR Hard-wired B C D E

  9. Example of connectivity across carriages. A C B D E A B C D E A A C C B B D D E E • Change request – “Activate Credit Control before step B (“Invoicing”) instead of step D (“Delivery”). Conventional approaches A B C D E After 3 years, … … the system HAS TO BE redesigned.

  10. Example of connectivity across carriages. A C B D E A A A A C B C A B C B C C D E A C B D D D D D E E E E E • How Modular Approach handles changes … Conventional approaches Modular Approach Monolithic OR Hard-wired

More Related