Programming for Business: Real People, Real World


Published on

We were taught computing science and software engineering methodologies, and tools. But in the end of the day, it's people who built software for people, not machines for machines. This presentation studies the possibilities and potentials of realising the human factor in software development and maximising revenues through the enrichment of creative people.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Programming for Business: Real People, Real World

  1. 1. Software Development Forum 2012Programming for Business: Real People, Real WorldMarshal YungSoftware Engineering & Architecture
  2. 2. BackgroundMe, Myself, and Software
  3. 3. Background● 1999 ● C++ MFC, integration API, PKI, CRM, ERP, etc.● 2004 ● Software engineering and project management ● Web services, open source, e-commerce ● Corporate trainer – Internet technologies – LAMP platform
  4. 4. Background● 2008 ● Software architecture design and build● 2010 ● PAP for Internet Technology (Tunku Abdul Rahman College) ● Platform & framework design and build● Now ● Independent software project manager ● Web OS ● Coding as a hobby, passion in software engineering & architecture
  5. 5. Overview
  6. 6. Overview● Software Functionality ● Building software for businesses ● Functionalities that people really want● Programs Significance in Business ● What goes in and what doesnt? ● Users and UX● Costs vs. Returns ● Software estimations and revenue models ● Real People, Real World
  7. 7. Software Functionality
  8. 8. Software Functionality● Why do we build software? ● To solve a certain problem ● i.e. Business analytics, computation logics, etc. ● To make life easier (for some) ● To automate repetitive (mundane) tasks ● To get more tasks done in shorter time ● Because were paid to do it
  9. 9. Software Functionality● Defining the software ● Functional requirements – Intricate details of software operations (functionality) ● Non-functional requirements – Compliance, business goals, standards, etc.● Quality software: ● Verifiable with functional requirements ● Comply with non-functional requirements
  10. 10. Software Functionality● Heres the irony ● When programmers build software for themselves – Its always minimalistic, usable, quick to deploy, and has only the necessary functionalities ● When programmers build software for others – Its always bloated, perplexed, delayed, and has many rarely needed functionalities
  11. 11. A Quick ExampleAn Appointment SchedulerFor Personal Use For OthersMonthly view calendar Monthly, daily, weekly view calendarsScroll by month and year Scroll by month and yearPop-up appointment entry Pop-up appointment entrySupport only single calendar Support multiple calendars Colour codedAppointment list view (shows date/time and Appointment list view (shows start-endappointment name) only for the selected day date/time, appointment name) sorted by day in the weekComplete CRUD operations Complete CRUD operationsSimplified recurring events (i.e daily, weekly, Recurring events (daily, day-weekly,monthly) weekday-weekly, weekend-weekly, monthly, yearly) Simple calendar sharing (non-server based) Import calendar (i.e. csv, ical, etc.)E-mail reminder (cron or scheduler based) E-mail + pop-up reminder (daemon based)UI concept: minimalistic, uncluttered UI concept: uncluttered, icons, widgets, etc.Deployment time: around 4 man-hours Deployment time: around 8 man-hours
  12. 12. Software Functionality● Functionalities for real people, real world ● Meets definition of a quality software – Verified and validated – People already knows what the software does, and they just want to get their job done ● Non-bloated software – Keep the good-to-haves for the next release – Remember to KISS! ● Sensible and consistent UI – No surprises – Meets general user expectations
  13. 13. In Retrospect● Consider practicality in the real world ● Must-haves vs. good-to-haves ● Agile development methodology ● Evolutionary prototyping and incremental development
  14. 14. Finding the Significance of Each Program in theBusiness World
  15. 15. “Every program that is created must have a purpose; if it does not, it is deleted” - Rama-Kandra, The Matrix Revolutions
  16. 16. User Centric Applications● Who are your users? ● Business users falls into various types ● Identifiable by business units ● Each business unit have unique requirements● Programs that benefit users ● Getting the job done ● Work as expected (rarely exceed expectations) ● User satisfactions – Expectations and perspectives
  17. 17. Use Case Diagram● Straight forward communication ● Business people ● End-users● For the technical team ● Clearly defines requirements and features● For the non-technical team ● Validity of requirements
  18. 18. Use Case Diagram
  19. 19. User Experience (UX)● Whats UX? ● A personal experience of a user towards a system ● Personal experiences including all things from aesthetics to usability ● A good personal experience (good UX) gives higher rate of acceptance
  20. 20. Programming in the Real World● Consider these ● Divide and conquer ● Each program (or function) should do only one job, and does it exceptionally well ● Learn from: – GNOME, Apple, Mozilla Project
  21. 21. Costs vs. Returns
  22. 22. Software Estimations● Justification of software values ● Based on effort and time spent ● May also include other costs; i.e. hardware and other incurred charges
  23. 23. Software Estimations● Function point analysis ● Quick and easy way to determine the amount of functionalities required ● Does not include costs outside software development effort (i.e. Hardware, training, etc.) ● Basis of cost per function is based on experience from past projects
  24. 24. Software Estimation● COCOMO/COCOMO II ● Constructive Cost Model ● Measurement of software costs and durations ● Derived from per-man-month effort and expressed in KLOC ● COCOMO II takes more considerations of PM attributes and modern software development processes (i.e. CMM-I levels)
  25. 25. Revenue Models● License based ● Client access license (CAL), per-seat, per-installation license, bulk license ● Common for install-based applications● Subscription based ● Per user/month, per user/year, bulk subscriptions ● Common in SaaS environment● Utility based ● Pay per-use ● Common in SaaS and cloud-computing environment
  26. 26. Software Returns – Real People● Maximise values of creative people ● Who are the creative people: – Programmers, designers, engineers ● Understanding creative people: – Creativity cannot be confined – Creative people has to be let loose to explore – Creative ideas come from the wild, not within cubicles
  27. 27. Software Returns – Real People● Communicating with creative people ● Business people: top-down approach ● Creative/technical people: bottom-up approach ● Requirements should be delivered in the form of – What is needed? – Not how to do it ● Business people lead business domain requirements ● Creative people lead the process of design and build of the requirements
  28. 28. Finally...● Programming for real people, real world ● Who are your users? They are very important (but not always right) ● Let creative people free to explore possibilities ● Business people ensure project direction and goals ● SDLC and methodologies are important ● But, let people build software for people
  29. 29. Thank You Q&A
  30. 30. Marshal YungSoftware Development Forum 2012Programming for Business: Real People, Real World