Maker Pro
Maker Pro

The software development process.

D

David L. Jones

Jan 1, 1970
0
Boki said:
Hi All,

Could you please advice how you provide the software development
process ?

I need some example to reference.

In my understanding is:

1. Specification list and discussion.
2. Solution and schedule proposed.
2.1 Critical task analysis
2.2 Other task list.
2.3 Schedule estimation.
3. Development and Test.
3.1 Finish critical task.
3.2 Development and test function block as unit.

4. System level / prodcut test

5. Mass production.

Depends on the size and type of the project. Many projects simply
involve:
1. Write code
2. Test code
3. Release

Some people skip step 2
Advanced projects might have an extra first step that constitutes
drawing a flow chart or psudeo code on the back of a napkin while
eating your McDonalds breakfast.

Seriously though, some project timeframes simply allow no time for
anything but coding and getting the first release out ASAP. I've had
software project timeframes that range from "get it done by the end of
the day or we're screwed" to 12 months were you have the luxury of
using (or are forced to use, depending on your viewpoint) formal
processes.

Dave :)
 
J

John Larkin

Jan 1, 1970
0
Depends on the size and type of the project. Many projects simply
involve:
1. Write code
2. Test code
3. Release

But better is to...

1. Write code
2. Read code
3. Test code
4. Release

but most people skip 2, sometimes 3, and even 4, in the sense that
they don't formally release it, they just sort of set it free in the
wild.
Seriously though, some project timeframes simply allow no time for
anything but coding and getting the first release out ASAP. I've had
software project timeframes that range from "get it done by the end of
the day or we're screwed" to 12 months were you have the luxury of
using (or are forced to use, depending on your viewpoint) formal
processes.

But the fastest way to get it working is to slow down and do it right.

John
 
J

John Woodgate

Jan 1, 1970
0
In message <[email protected]>, dated Sun, 10
Sep 2006 said:
But better is to...

1. Write code
2. Read code
3. Test code
4. Release

but most people skip 2, sometimes 3, and even 4, in the sense that they
don't formally release it, they just sort of set it free in the wild.
I agree, but why are programming languages (except vintage BASIC)
written so as to be nearly (or quite) unreadable by humans?
But the fastest way to get it working is to slow down and do it right.

Such dangerously revolutionary ideas should be banned from Usenet.
 
M

mc

Jan 1, 1970
0
But the fastest way to get it working is to slow down and do it right.

Amen! Quote for the week!

My other advice is not to disparage error-detecting tools (of any kind) or
error-preventing disciplines as "training wheels." Too many programmers
want to ride without training wheels or without a helmet. But surely the
one thing every programmer knows is his own fallibility.
 
M

Michael A. Terrell

Jan 1, 1970
0
mc said:
Amen! Quote for the week!

Too many programmers
want to ride without training wheels or without a helmet.


And the code the release shows the brain damage from falling on their
head too many times. ;-)


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
 
J

John Larkin

Jan 1, 1970
0
In message <[email protected]>, dated Sun, 10

I agree, but why are programming languages (except vintage BASIC)
written so as to be nearly (or quite) unreadable by humans?

You refer of course to write-only languages like C++. It's because the
practitioners enjoy the cryptic-ness of it all, and are usually inept
at the use of real (human) languages. Posters to this group have noted
that, if they take over someone else's C code, they first run it
through a comment stripper.

I like to program in PowerBasic for PC-type stuff (engineering apps
and test software) and assembly for embedded stuff, both heavily (and,
I hope, literately) commented.


John



.SBTTL . MACRO : GEAR

; SIMULATE A GEAR PATTERN WITH POSSIBLE SHORT TEETH
;
; MACRO PARAMS ARE...
;
; 0 CHANNEL NUMBER
; 1 START POINTER
; 2 NUMBER OF PULSES 'N' 1..512
; 3 DC BASELINE
; 4 WAVESHAPE (NOT IMPLEMENTED YET)
; 5 TOOTH WIDTH
; 6 DEFAULT TOOTH HEIGHT
;
; 7 SHORT PULSE INDEX 1..N } REPEAT, UP TO 16
; 8 SHORT PULSE HEIGHT } EXCEPTION TEETH

; A0 SWEEPS PARAMETERS
; A1 AIMS AT PTRn REGISTER
; A2 AIMS AT WAVn
; D0 PULSE LEVEL
; D1 IS BLOCK START POINTER
; D2 PULSE POSITION, NORMALIZED
; D4 TOOTH WIDTH, AS DBF
; D5 TOOTH INDEX, 0..N-1
; D6 TOOTH COUNT N


GEAR: MOVE.W MP0.W, D0 ; FETCH CHANNEL NUMBER
JSR MAPP.W ; AND MAP SOME STUFF
TST.W D7 ; DID THAT WORK?
BNE BADMAC ; NOPE.

LEA.L WAVX(A1), A2 ; AIM A2 AT WAVn REGISTER
LEA.L PTRX(A1), A1 ; AND A1 AT PTRn

MOVE.W # 0300h, D7 ; ANTICIPATE ERROR CODE 3
; == ILLEGAL TOOTH COUNT ==

MOVE.W MP2.W, D6 ; EVAL NUMBER OF TEETH:
BEQ BADMAC ; 0 IS SILLY, FOLKS.
CMPI.W # 512, D6 ; CHECK LEGALITY
BHI BADMAC ; BAIL IF TOO MANY

; FIRST, FILL THE WAVE BLOCK WITH THE BASELINE VALUE

MOVE.W MP1.W, D1 ; GET START LOCATION
MOVE.W D1, (A1) ; POKE FPGA 'START' POINTER
MOVE.W BSIZ.W, D7 ; AND NAB BLOCKSIZE
SUBQ.W # 1, D7 ; -1 FOR SILLY 'DBF' LOGIC
; WHICH *DOES* WORK OK FOR 65536!
MOVE.W MP3.W, D0 ; FETCH THE GEAR ROOT LEVEL

GROOT: MOVE.W D0, (A2) ; POKE BASE VALUE INTO RAM
DBF D7, GROOT ; FOR THE WHOLE BLOCK

; NOW LOAD THE BASIC GEARTOOTH PATTERN

CLR.L D5 ; START WITH TOOTH # 0
MOVE.W MP6.W, D0 ; AT THE DEFAULT TOOTH HEIGHT
MOVE.W MP5.W, D4 ; GET NORMALIZED TOOTH WIDTH
MOVE.W DNORM.W, D7 ; AND DENORM FACTOR
BEQ.S BEER ; 0 MEANS DON'T SHIFT!
LSR.W D7, D4 ; ADJUST WIDTH TO ACTUAL BLOCK SIZE
BEER: TST.W D4 ; DID WE CRUSH WIDTH TO ZERO?
BEQ.S NORTH ; DBF COUNT OF ZERO MAKES WIDTH 1!
SUBQ.W # 1, D4 ; OR ELSE USE REQUESTED WIDTH, DBF FORM.

NORTH: JSR TOOTH.W ; CREATE ONE TOOTH
ADDQ.W # 1, D5 ; COUNT IT DONE
CMP.W D6, D5 ; DONE ALL, 0 TO N-1?
BLO.S NORTH ; HANG IN THERE, KID.

; NOW DO THE EXCEPTIONS: FOOLISHLY, WE IDENTIFIED THE EXCEPTION
; TEETH AS 1..N, SO WE'LL HAVE TO ATONE FOR THAT.

MOVEA.W # MP7, A0 ; AIM AT FIRST POSSIBLE EXCEPTION ENTRY
MOVE.W # 16-1, D2 ; ALLOW UP TO 16 EXCEPTION TEETH

TOPIX: MOVE.W (A0)+, D5 ; NAB THE TOOTH INDEX
BEQ.S GROUT ; AN INDEX OF 0 ENDS THE LIST
CMP.W D6, D5 ; IF INDEX IS SILLY,
BHI.S GROUT ; WE'LL QUIT AS WELL.

SUBQ.W # 1, D5 ; OK, ADJUST THE INDEX.
MOVE.W (A0)+, D0 ; FETCH THE 'SHORT' PULSE HEIGHT
JSR TOOTH.W ; AND OVERWRITE STANDARD GEAR TOOTH
DBF D2, TOPIX ; DO ANOTHER TOOTH, MAYBE.

GROUT: JMP OKAY.W ; DONE THE LAST OF THE MEAN MOLDY MACROS!
 
J

John Larkin

Jan 1, 1970
0
My other advice is not to disparage error-detecting tools (of any kind) or
error-preventing disciplines as "training wheels." Too many programmers
want to ride without training wheels or without a helmet. But surely the
one thing every programmer knows is his own fallibility.

Don't I wish. The only way to deliver good code is to assume that the
author is a sloppy idiot whose work must be kept as simple as possible
and checked at least twice.

John
 
H

Homer J Simpson

Jan 1, 1970
0
But better is to...

1. Write code
2. Read code
3. Test code
4. Release

You seem to have missed the most important step

0. PLAN the code.

"Those who fail to plan, plan to fail".

"Every failed project goes wrong in the first two weeks. After that, it is a
losing battle".
 
H

Homer J Simpson

Jan 1, 1970
0
I agree, but why are programming languages (except vintage BASIC) written
so as to be nearly (or quite) unreadable by humans?

Usually because no humans are involved.

Bill Gates' first 8080 Basic was somewhat bug ridden - but worked well
enough. I once saw a reproduction of the first page - it was almost all
comments. This is the sign of someone who knows what he is doing. I wonder
what ever happened to him?

There is nothing wrong with most languages. There is plenty wrong with the
people and the process used.
 
J

John Woodgate

Jan 1, 1970
0
In message <[email protected]>, dated Sun, 10
You refer of course to write-only languages like C++.
Yes.

It's because the practitioners enjoy the cryptic-ness of it all, and
are usually inept at the use of real (human) languages. Posters to this
group have noted that, if they take over someone else's C code, they
first run it through a comment stripper.

How is that different from an ordinary stripper?
I like to program in PowerBasic for PC-type stuff (engineering apps and
test software)

I can ONLY do BASIC, and now you wrote that I'm not ashamed to admit it.
(;-)
and assembly for embedded stuff, both heavily (and, I hope, literately)
commented.

It wouldn't win a pullet surprise (not an original JMW; a US schoolgirl,
I believe), but it is comprehensible.
 
J

John Larkin

Jan 1, 1970
0
You seem to have missed the most important step

0. PLAN the code.

"Those who fail to plan, plan to fail".

"Every failed project goes wrong in the first two weeks. After that, it is a
losing battle".

I program bottom-up, so the planning happens continuously during the
coding, not really before it begins. This only works if one is
ruthless about re-writing anything that's not perfect, and if step (2)
above results in substantial cleanup.

John
 
J

John Woodgate

Jan 1, 1970
0
dated Sun said:
There is nothing wrong with most languages. There is plenty wrong with
the people and the process used.

If every program has to start with:

main{

which does nothing, why bother with it?
 
R

Robert Adsett

Jan 1, 1970
0
John said:
I agree, but why are programming languages (except vintage BASIC)
written so as to be nearly (or quite) unreadable by humans?

Vintage BASIC is readable? Single letter variables and legions of
gotos. Nearly all programs I've seen written in vintage BASIC has been
excreable. Quite unreadable enough to be contenders in an obbsfucated
code contest.

Microsoft's and other vendors more recent structured variations are
much better having borrowed from other structured languages.

Robert
 
H

Homer J Simpson

Jan 1, 1970
0
I program bottom-up, so the planning happens continuously during the
coding, not really before it begins. This only works if one is
ruthless about re-writing anything that's not perfect, and if step (2)
above results in substantial cleanup.

I have my own little mental collection of massive program failures but I
wish there was a website to post the all on like

http://www.fuckedcompany.com/ - sort of http://www.fuckedprojects.com/ ?

perhaps if the FBI had read up on failures first?

I note that it's almost always large, complex database programs that fail.
 
H

Homer J Simpson

Jan 1, 1970
0
I can ONLY do BASIC, and now you wrote that I'm not ashamed to admit it.

Basic is cheaper to code and cheaper to maintain. You need a good reason to
use another language.
 
M

Michael A. Terrell

Jan 1, 1970
0
Robert said:
Vintage BASIC is readable? Single letter variables and legions of
gotos. Nearly all programs I've seen written in vintage BASIC has been
excreable. Quite unreadable enough to be contenders in an obbsfucated
code contest.

Microsoft's and other vendors more recent structured variations are
much better having borrowed from other structured languages.

Robert


Gee, I've picked up 20+ year old basic programs that I wrote and I've
had no trouble reading or modifying them.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
 
J

John Larkin

Jan 1, 1970
0
Basic is cheaper to code and cheaper to maintain. You need a good reason to
use another language.

PowerBasic is great. It's a serious compiler that lets you do almost
anything that the OS allows.

John
 
J

John Larkin

Jan 1, 1970
0
If every program has to start with:

main{

which does nothing, why bother with it?

It's the "subroutine" that the OS "calls" to run the program. It sort
of means START HERE. The Windows (32 bit) versions of PowerBasic all
start with PBmain() as a declared subroutine, so that poor little
Windows doesn't get confused as to what we want it to do.

John
 
J

John Devereux

Jan 1, 1970
0
John Woodgate said:
If every program has to start with:

main{

which does nothing, why bother with it?

So we know where the program is supposed to start?

Remember non-trivial programs are made from many different source
files. Also the parameters to main() can be used to access the
parameters given by the user on the command line.
 
J

John Larkin

Jan 1, 1970
0
Vintage BASIC is readable? Single letter variables and legions of
gotos. Nearly all programs I've seen written in vintage BASIC has been
excreable. Quite unreadable enough to be contenders in an obbsfucated
code contest.

Microsoft's and other vendors more recent structured variations are
much better having borrowed from other structured languages.

Robert

There are several "modern" BASICs around, and they can be quite
readable. But to be fair, you should compare GWBasic to 8088 assembly,
as they were contemporaries.


John


'
' BRICK.BAS : ROM-IMAGE FILE BUILDER
'
' by John Larkin
' Highland Technology, Inc
' 320 Judah Street
' San Francisco
' www.highlandtechnology.com
'
' November 9, 2000
'
' Copyright (c) 1999 Highland Technology, Inc.
'

' THIS PROGRAM WILL MAKE A ROM IMAGE FILE FROM MOTOROLA 'S28'
' FILES AND XILINX FPGA 'RBT' FILES.
'
' THIS VERSION CAN BUILD A ROM OF UP TO 4 MBITS (524288 BYTES).
' WE USE COMMAND-LINE ARGUMENTS TO SPECIFY BUILD PARAMETERS,
' AND CREATE LOG FILE BRICK.LOG TO DOCUMENT THE BUILD.
'
' COMMAND LINE SYNTAX IS DESCRIBED IN THE 'HELP' PROMPT BELOW.

' BRICK IS CODED FOR PowerBasic/CCv2.

' NOTE : NOV 9, 2000 VERSION FIXED CHECKSUM CALCULATION ERROR


#COMPILE EXE ' AS OPPOSED TO... WHAT?

#OPTION VERSION4 ' COMPILE FOR Hairball95

DEFLNG A-Z ' DEFAULT 32-BIT VARIABLES


FUNCTION PBMAIN() AS LONG

DIM ROM(524287) AS BYTE ' IMAGE WORKSPACE, 4194304 BITS

DIM H(100) ' HEX VALUES FROM INPUT STRING

DIM SP AS STRING PTR * 256 ' USED TO GOBBLE ROM() FOR OUTPUT

K256 = 256 ' A SCALER
K64 = 65536 ' DITTO

COLOR 15, 0 ' TURN UP THE LIGHTS!

'

' INPUT THE FILENAMES FROM THE COMMAND LINE...

Y$ = COMMAND$ ' TRY COMMAND LINE FIRST

IF Y$ = "" THEN ' NONESUCH? ALLOW MANUAL ENTRY

PRINT
PRINT " BRICK.EXE: Rom image builder Copyright (c) 1999 Highland Technology Inc"
PRINT
PRINT "Enter a command line as..."
PRINT
PRINT "OUTFIL.ROM/256 = MACFIL.S28 FPGA1.RBT/aaaa FPGA2.RBT/bbbb /C:cccc"
PRINT
PRINT " where..."
PRINT
PRINT " OUTFIL.ROM ROM-image output file. Specify ROM size"
PRINT " as /256, /512, /1M, /2M, or /4M"
PRINT
PRINT " MACFILE.S28 68332 uP code in Motorola S28 format. Filename"
PRINT " extension must be .S28 or .HEX.
PRINT
PRINT " FPGAn.RBT FPGA config file(s) in Xilinx RBT format;"
PRINT " ASCII header loads at aaaa, config data begins"
PRINT " at aaaa+100h. File extension must be .RBT.
PRINT
PRINT " /C:cccc Specifies address of optional 16-bit checksum"
PRINT
PRINT " /P:dddd@aaaa Pokes 16-bit value dddd at address aaaa"
PRINT

LINE INPUT "BRICK > " Y$
PRINT

END IF
'

Y$ = UCASE$(Y$) ' FORCE UPPERCASE
IF Y$ = "" THEN GOTO XNULL ' NO COMMAND? JUST EXIT

' OPEN AND BEGIN THE LOG FILE

OPEN "BRICK.LOG" FOR OUTPUT AS # 7

PRINT #7, " BRICK.EXE ROM BUILD LOG FILE "; DATE$; " "; TIME$
PRINT #7,
PRINT #7,
 
Top