How to be a good engineer ?

1
How to be a good engineer ?

• Phantom Weng, Openfind RD VP

2
Engineering

• Programmers
• No engineering, just do it
• Engineers
• Balance between ideal world and real world
• Solving problems with disciplined and systematic
  approaches
• Scientists/Researchers
• Looking for a perfect model

3
????

• main()
• char s10
• strcpy(s,abc)
• addExt(s)
• printf(s,s)

void addExt(char s) strcat(s,.dat)
4
????
define SUCCESS 0 define ERR_PARAM -1

• main()
• int ret 0
• char s10
• strcpy(s,abc)
• ret addExt(s,10)
• if (ret ! SUCCESS)
• // Error Handling
• else
• printf(s,s)

int addExt(char s) if (s NULL)
return ERR_PARAM strcat(s,.dat) return
SUCCESS
5
????
define SUCCESS 0 define ERR_PARAM
-1 define ERR_BUF_SIZE -2

• main()
• int ret 0
• char s10
• strcpy(s,abc)
• ret addExt(s,10)
• if (ret ! SUCCESS)
• // Error Handling
• else
• printf(s,s)

int addExt(char s,int nLen) if (s NULL)
return ERR_PARAM if (strlen(s)strlen(.d
at) gt nLen) return
ERR_BUF_SIZE strcat(s,.dat) return
SUCCESS
6
????
define SUCCESS 0 define ERR_PARAM
-1 define ERR_BUF_SIZE -2
define LEN 10 define EXT .dat

• main()
• int ret 0
• char sLEN
• strcpy(s,abc)
• ret addExt(s,LEN)
• if (ret ! SUCCESS)
• // Error Handling
• else
• printf(s,s)

int addExt(char s,int nLen) if (s NULL)
return ERR_PARAM if (strlen(s)strlen(EXT
) gt nLen) return ERR_BUF_SIZE
strcat(s,EXT) return SUCCESS
7
????
define SUCCESS 0 define ERR_PARAM
-1 define ERR_BUF_SIZE -2
define LEN 10 define EXT .dat

• main()
• int ret 0
• char sLEN
• strncpy(s,abc,LEN)
• sLEN-1 \0
• ret addExt(s,LEN)
• if (ret ! SUCCESS)
• // Error Handling
• else
• printf(s,s)

int addExt(char s,int nLen) if (s NULL)
return ERR_PARAM if (strlen(s)strlen(EXT
) gt nLen) return ERR_BUF_SIZE
strncat(s,EXT,nLen-strlen(s)-1) snLen-1
\0 return SUCCESS
8
????
define SUCCESS 0 define ERR_BASE
0 define ERR_PARAM ERR_BASE -
1 define ERR_BUF_SIZE ERR_BASE - 2 define
LEN 10 define EXT
.dat
9
Learn from our or others prior failures.

• Why projects fail?
• Poor scheduling
• Poor planning
• Poor management
• Bad organization structure
• Uncontrolled requirements
• Unmanaged changes
• Are these reasons technical?

10
Planning a software project

• Everyone knows we need to have a plan, but why we
  dont have it
• Release pressure and tight schedule
• We only have time to testing and coding, anything
  else is unnecessary and can be skipped
• But, actually, having a sound plan is the only
  way to meet the aggressive schedule.

11
Duties for an Engineer

• Feasibility study
• Technical design with alternatives
• Schedule estimation and meet it
• Robustness and quality
• Your work can be reproduced
• Your work can be maintained

12
Bad Schedule Estimation

• ????
• ?????????
• ???? integration effort
• ???? testing and debugging effort
• Perfect Man-month partition

13
The Man-Month
14
Time requirementsSuggested by Fred P. Brooks, Jr.

• Planning
• Coding
• Component test and early system test
• System test with all component in hand

1/3 1/6 1/4 1/4
15
How to estimate schedule

• Do not optimism. Always keep buffer.
• More details you consider in the design stage,
  more accuracy about your estimated schedule.
• Break large module into small modules.
• Do not forget the effort of integration.
• Use intermediate milestone to control.
• Learn from mistakes.

16
Design

• Review by others
• Must have alternatives
• Design more
• Well-document
• Invite related people to join design
• Start thinking about integration at this stage
• Control bugs
• UI samples

17
????

• ???????????
• ?????????????,?? escalate
• ???????????????????
• ??????,???????????,????????????

18
Thank You ??????????