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.

1. Software Development Forum 2012
Programming for Business: Real People, Real World
Marshal Yung
Software Engineering & Architecture

2. Background
Me, Myself, and Software

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. 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. Overview

6. Overview
● Software Functionality
● Building software for businesses
● Functionalities that people really want
● Program's Significance in Business
● What goes in and what doesn't?
● Users and UX
● Costs vs. Returns
● Software estimations and revenue models
● Real People, Real World

7. Software Functionality

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 we're paid to do it

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. Software Functionality
● Here's the irony
● When programmers build software for
themselves
– It's always minimalistic, usable, quick to deploy,
and has only the necessary functionalities
● When programmers build software for others
– It's always bloated, perplexed, delayed, and has
many rarely needed functionalities

11. A Quick Example
An Appointment Scheduler
For Personal Use For Others
Monthly view calendar Monthly, daily, weekly view calendars
Scroll by month and year Scroll by month and year
Pop-up appointment entry Pop-up appointment entry
Support only single calendar Support multiple calendars
Colour coded
Appointment list view (shows date/time and Appointment list view (shows start-end
appointment name) only for the selected day date/time, appointment name) sorted by day
in the week
Complete CRUD operations Complete CRUD operations
Simplified 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. 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. In Retrospect
● Consider practicality in the real world
● Must-haves vs. good-to-haves
● Agile development methodology
● Evolutionary prototyping and incremental
development

14. Finding the Significance of Each Program in the
Business World

15. “Every program that is created must have a
purpose; if it does not, it is deleted”
- Rama-Kandra, The Matrix Revolutions

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. 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. Use Case Diagram

19. User Experience (UX)
● What's 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. 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. Costs vs. Returns

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. 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. 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. 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. 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. 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. 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. Thank You
Q&A

30. Marshal Yung
Software Development Forum 2012
Programming for Business: Real People, Real World