programming for business: real people, real world
TRANSCRIPT
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