SOFTware is HARD

Recently, I had the chance to play with SharePoint lists and Document Libraries. I also had the challenge of using SharePoint without the use of Designer. In creating a List or Document Library and associating it with a Workflow, my challenge was to create a View such that I could filter it based on the Workflow status. Thanks to the wisdom of the internet crowd, I chanced upon this article here The status of each workflow is stored as a numeric value but displayed as a string description as follows: NotStarted = 0 FailedOnStart = 1 InProgress = 2 ErrorOccurred = 3 StoppedByUser = 4 Completed = 5 FailedOnStartRetrying = 6 ErrorOccurredRetrying = 7  ViewQueryOverflow = 8 Canceled = 15 (to be confirmed)  Approved = 16 Rejected = 17 (to be confirmed) To filter, compare the value against a numeric constant. For example: show only those that are in progress: = 2 show only those that are not completed: < 5 show only those approved: = 16

Capture user stories in the form of: As a <user role/type> I want <some action/ feature/ goal>, so that < benefits from/ reasons for it> Capture acceptance tests in the form of: GIVEN (some context/precondition) [ AND (some more context/precondition) ...] WHEN (event/action performed by user) THEN (expected outcome - what should happen to satisfy user requirement from the user story statement above). See https://www.infoq.com/articles/standardize-requirements-scrum

I was once involved in reviewing our company’s application architecture to identify security risks and recommend possible mitigation solutions. Since every organisation has its own unique constraints, available resources, and risk appetite, the solution herein might not apply to other organisations. Nevertheless, this post showcases what one can do with UML to document and explain (pictorially) security flaws in application architecture. The as-is architecture follows. A detailed explanation follows: The system (under design) is a Java Enterprise Application that is deployed in AppSvr (Application Server) within the Internal zone. The deployed application consists of both HTML-based as well as SOAP-based services. The 2 WebSvr’s ([Apache] Web Server) in the DMZ act as proxies. There is a load-balancing appliance used to balance requests to the web servers. A request pool has been created on the appliance (WebPool). The (public) user would access the URL endpoint of the appli

I had the opportunity to develop a prototype for a client and used Astah to capture the salient specifications as well as the requirements analysis. Mindmap To first understand the requirements, I used a mindmap to guide the user through the mean features of the application. What worked well in this instance was a role-based model (similar to use case modelling), i.e. list out all the roles involved in interacting with the application. Next, the features or use cases for each role gets listed out (“as a <role>, I want to be able to <feature>”) The final mindmap served as a form of an agreement on the scope of work. The final mindmap looked like the following:   Use Case Modelling Using Astah, I was able to easily convert the Mindmap into a set of Actors and Use Cases for further analysis. The model follows:   Domain Model As the prototype had dependencies on an existing application, some of the domain objects were deliberately taken from the the existing app