Software Development Forum 2012Programming for Business: Real People, Real World

Marshal YungSoftware Engineering & Architecture

BackgroundMe, Myself, and Software

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

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

Overview

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

Software Functionality

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

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

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

A Quick ExampleAn Appointment SchedulerFor 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 name) only for the selected day

Appointment list view (shows start-end date/time, appointment name) sorted by day in the week

Complete CRUD operations Complete CRUD operations

Simplified recurring events (i.e daily, weekly, monthly)

Recurring events (daily, day-weekly, 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

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

In Retrospect

● Consider practicality in the real world● Must-haves vs. good-to-haves● Agile development methodology● Evolutionary prototyping and incremental

development

Finding the Significance of Each Program in the Business World

“Every program that is created must have a purpose; if it does not, it is deleted”

- Rama-Kandra, The Matrix Revolutions

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

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

Use Case Diagram

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

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

Costs vs. Returns

Software Estimations

● Justification of software values● Based on effort and time spent● May also include other costs; i.e. hardware

and other incurred charges

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

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)

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

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

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

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

Thank You

Q&A

Marshal YungSoftware Development Forum 2012

Programming for Business: Real People, Real World