Categories
Risk Management

Process flow + Sequence Diagram – Mixed Breed of UML

As most of job scope of my previous job in BCSIS is to support the application, on my own I have created plenty of own version internal ‘software document’. I think some of these documents are mixed breed between process flow diagram and sequence diagram 🙂 Nevertheless, this is my favorite internal document as I can easily understand the flow of the system just by some quick glance. I also converted some source code into some flow chart diagrams (again my version).

In fact, I do enjoy and satisfying creating all these diagrams. And I did the same for my Product Management department as QC Manager in GHL. By the way, I just use Ms Power Point. No need expensive tool like Visio 🙂

Here are the entire list of ‘Process flow + Sequence’ diagram documents which I have created. Yes, the sample diagrams are a little ‘unclear’ for reasons. To view the ‘clear’ version and to view more diagrams, you can contact me personally ya.

CTCS Gateway Interface (GWC)

  • EPKI – Outward – GWC and Bank Host
  • Inward  Downloading – ISC, GWC and Bank Host
  • Transmission – OCS and GWC
  • Transmission – OCS and PODClient

Bank and BNM Web

  • Branch and Routing Policy Request

Bank Negara Malaysia (BNM) – Back End Host

  • Inward Generation
  • Generate Billing
  • Generate Settlement File
  • File and Data Archival
  • Report

CSS / RBE / FMS

  • Billing and Settlement @ CSS
  • SQL Server Agent Job @ CSS

Others

  • Swing CTCS – HQ and Recovery Center
  • Host Support Escalation

Product Management

  • Activate Dialogic Card (only for PRI card type)
  • Certificate of Origin – Special Case
  • Check warranty period and SLA maintenance
  • Product Request
  • Supply Chain Management – Procurement / Production
  • Supply Chain Management – Distribution
  • New Project or Change Request

 

 

 

Categories
Risk Management

Sediakan Payung Sebelum Hujan

 

 

Sediakan Payung Sebelum Hujan

Hujan is still okay, but what if it is Storm? Again, here is a classic scenario as illustration purpose. 🙂 Here, we focus on the twist plot – no one resign but the whole office caught fire and all the laptops are destroyed completely.

Actually, this can really happen. Although Malaysia is fortunate enough to be protected by most natural disaster, we should not take this for granted. Disaster can still happen and the common ones are fire. Hence, Bank Negara (Central Bank) requires all the financial institution (FI) like banks to have Business Continuity Planning (BCP) or Business Continuity Management (BCM). The main objective is about RISK management.

file00093561951

In my previous company, we also performed this BCP every year by going to Bank Negara, restoring our core applications and ensure that our core applications works. I remember there was once I had a argument with my manager just because of I refused to ‘amend’ the BCP form, so that the company can ‘pass’ the BCP. Same goes with my current company when I was doing Terminal Quality Management (TQM) which is required my MasterCard for one of our products certification process. But, that’s another story all together 🙂

For more info – Operation Risk Management Concept Paper by Bank Negara Negara

 

Categories
Risk Management Software Engineering

The BIG Dilemma – Should I re-build the good old house?

One of the biggest consideration and dilemma as a software engineer is, should I re-design the system design and clean up the source code or not?

rebuild.

Here is a classic scenario as illustration purpose.

If Mutu’s source code is well designed and clean, Sally is considered lucky to pick up his role to continue and maintain his source code. Otherwise, it will be a nightmare for Sally to try to figure out his design and the dilemma on whether to clean up his source code. Why dilemma to re-design/revamp the system? Cleaning up code is good provided you are well-verse with the entire system design. The main benefit of a clean, organized and well-design system is maintainability. Although I don’t consider myself a talented software engineer, developing a well-maintained source code is one of my principles. I would rather spend a little more time to make the source code more maintainable, so that I don’t have to have sleepless night and headache troubleshooting bugs and for future enhancement.

But, for a large and critical system whereby there were many software engineers have ‘touch’ on the source code, usually new software engineer will opt to take the safer path by not making any unnecessarily big changes, be it to clean the source code or to re-design the system. Re-design the system can cause big impact to the entire system and highly susceptible to bugs too. Much effort is needed also to re-test the new re-vamped version.

Categories
Risk Management

This classic scenario rings a bell?

A team of five including the team lead, Wong are working on a software project. That project was given nine months time frame. The project went well and ‘on track’ for the first six month until one senior software engineer, Mutu tendered his resignation letter with one month notice. Upon receiving the ‘bad news’, Wong immediately notified the HR manager, Nurul. Few days later, she informed her staff to process for the new hiring. A week later, the advertisement was out in Jobstreet.

For the past six months, Wong and his team members including Mutu had been busy focusing in software development. Some documents were created along the way but there are ‘everywhere’. Some in his own laptop while some were in his team member’s laptop. That included the software modules in charged by Mutu. But these documents available are mainly high-level documents like use cases and initial functional specification.

Bear in mind, that Mutu is a quick-pace and strong-domain knowledge software engineer. Otherwise, he won’t sustain the in the company for four years. But, just like most software engineers, he hardly creates any own lower-level software document like flow-chat diagram, sequence diagram, test plan and release notes. Why? God knows. Maybe this is common among most software engineers; so that the company will always need and rely on them. But with software documents in place to understand the design of the system faster, they afraid that any new staff can replace them. Moreover, Wong also didn’t request for all the low-level of software document what. Maybe. Just my guessing.

At this point of time, the project time line is not longer ‘on track’ due to the extra time Mutu spend to prepare hand-over and for Wong’s time for Mutu’s hand-over sessions. All these hiccups were not factored in during project planning in the beginning. A week before left the company, he could only hand-over a couple of documents and all the source code to Wong. But due to heavy work load as a team leader, Wong has only limited time to attend and learn from Mutu’s hand-over sessions. Imagine how much stuff left over by someone who worked for four years. Hence, Wong just copied all those little software documents and all the source code in his external hard drive.

All in all, the hiring process took about two months. By the time, the new software engineer, Sally came in, Mutu had already left the company for a month. Wong met up with Sally and ask her to copy all the resources and Mutu’s source code from his external hard drive to her laptop and explain to her briefly the project they are working right now and ask to her those documents created by Mutu last time. As Sally went through those document, she realized that those software document are not in sync with the source code. Hence, she took quick a long time to really understand the modules developed by Mutu last time. And this cause more project delay and we all know time is money. The domino effects continue from one generation to another.


Two possible twist in the plot: Can the above scenario became worse? Can the project ‘survives’ and meet the project deadline? What if

  • Wong also resigned one week after Mutu tender his resignation letter.
  • No one resign but the whole office caught fire and all the laptops are destroyed completely.
Categories
Risk Management

Why some companies especially banks require their staff to take ‘Block Leave’?

In my previous company, every year, we need to take this mandatory block leave. It is a special annual leave whereby the annual leave is in a ‘block’ form once a year. During this period, the company is not allowed to contact you and vice versa. An executive level might have a longer block leave compare to a non-executive.

During your block leave period, if you company contacted you for some critical reasons, your block leave is considered void. And when it is void, you need to re-take the block leave again. If you do not have enough annual leave for your block leave, you need to take unpaid leave for your block leave.

 

Block-Leave

So, what is the purpose of a company imposing their staff to take block leave? The answer is risk management, to make sure that the company can still operate as usual without your presence. Just imagine, a bank has this only one employee who can support a critical system. And one fine day, he went missing in action. It can be due to many possibilities. Emergency. Accident. Critical illness. What will happened to the bank? Another word, by imposing block leave, this will ensure that there is replacement for every staff.

Not all company impose block leave, only those from banking industry or those companies which need to support critical systems.

Even with this scenario of senior software engineer resigned, the entire team is more prepared. At least, for the past four years, we know that the company survives when Mutu took block leave.