Explaination of the program life cycle and its components

The program development life-cycle has 6 phases

1. Define the problem
2. Design the solution
3. Code the program
4. Test the program
5. Document the program
6. Implement the program

In this post I will further define these phases

Define the problem

• Determine the program requirements – What should it do?
• Usually this means meeting with analysts/users
• Identify the program components – Input, processing, output (IPO)

Design the solution

• Design an algorithm for a solution to the problem
• An algorithm is a series of logical steps required to solve a particular problem
• Design tools help to break down the problems and describe the solution

Design tools

• Flow charts to show the steps in the algorithm
• Structure charts to show program flow
• Desk checking to validate the solution

Flowcharting

• A flow chart is a graphical representation of an algorithm
• Each step is represented by a symbol and the arrows indicate the flow and order of the steps
• The shape of the symbol indicates the type of operation that is to occur
• Flow charts may help the more visual students learn and understand logic

Structure charts

• Structure charts like flow charts are graphical
• They show the order in which each step in the algorithm should be performed – the program flow
• They also show the logic that determines the order

Desk checking

After designing a solution, make sure it is going to work before coding it by desk checking it.

1. Develop sets of test data (inputs)
2. Determine the expected result (output) for each data set without using solution algorithm
3. Step through solution using one set of test data and writing down actual result obtained (output)
4. Compare expected results with actual results
5. Repeat steps 3 and 4 for each set of test data

Code the program

• Translate the solution algorithm into a programming language
• Enter program code into a programming development tool using the correct syntax

Test the program

• Remove the syntax and logic errors
• Syntax error – when code violates the programming languages rules
• Logic error – when the program does not generate expected output when using the test data
• Logic errors are also called bugs, so finding and fixing bugs is referred to as ‘debugging’
• Debugging tools – some errors are difficult to find so programmers use a debugger that allows them to walk through the as each statement is executed

Document the program

Programs should be documented so that others can easily understand and change them

Details include:

• A narrative description of the program
• Comments in the program that explain what is happening
• Flow charts, IPO charts and structure charts
• Testing procedures

Implement and maintain the program

• The program(s) are installed on the clients system
• Training, user manuals, user upgrades and conversions must be taken into consideration during the implementation
• Eventually programs may need to be updated due to mandatory updates such as government regulations or changes in the way the business operates
• Programs may be enhanced to add new features or functionality
• Programs may become obsolete when changes become too difficult or new technology becomes available. When this happens, the program development life cycle starts again

Input, Processing and Output (IPO charts)

Many programs use three steps:

1. Gather input data – from the keyboard, from files on disk drives
2. Process the input data
3. Display the results as an output – Send it to the screen, write it to a file.

JAG Assignment details

Need to create/ recommend a database

Designing output

Questions:

Purpose of output

Who wants the info, why do they need it, how the info will be used

What specifics will be included

Is the output printed, onscreen or both, what devices will the output go to?

Types of outputs

In systems design phase you create forms, reports, docs and other types of output these are used in different types of media such as internet, email, IM, wireless devices etc

User importance in report design

Recipients should approve all report designs in advance

You should submit each report as you design it for approval

Report design principals

• Attractive, proffessional, easy to read
• Report headers/ footers
• Page headers/ footers
• Column heading alignment
• Column spacing
• Field order
• Grouping detail lines

Report design issues

• Uniform and consistant
• Each report should share common design elements
• Document the design in a report analysis form

 

User interface design

Evolution of user interface

• Process control
• User centered system
• Process use to rule how things were done, now it is more user based.

Human-computer interaction (HCI)

This is the relationship between humans and computers

The main objective is to create a user friendly design that is easy to learn and use

Basic principals of user based design

• An understanding of the underlying business functions
• Maximum graphic effectiveness
• Profile the system users
• Think like a user
• Use prototyping
• Use a storyboard/ mockup

 

Pricipal of user centered design

• Usability metrics
• Design a comprehensive interface
• Continue the feedback process
• Document the interface design

 

Input and data entry methods

Online data entry etc

Input volume: The guidelines will help with this

1. Input necessary data only
2. Do not input data that the user can retrieve from the system files or calculate from other data
3. Do not input constant data
4. Use codes

Data entry screens

The most effective method of online data entry is form filling

1. You should restrict data access
2. Use a descriptive caption for each field

What is a system?

Input –> Process –> Output –> Feedback (continuous loop)

Input– Anything that goes into the system

Process– The process that results in the output

Output– The result of the process

Feedback– Information from the previous cycle used to change the process in proceeding cycles

System enviroment

system boundary- defined by the rules placed on the particular system, often difficult to define the exact boundaries of a system

input- Only occurs in open systems, any information that is put into a process

output- The result from the process

feedback- Information gathered from an output used to change the way/choices the system makes the next time it runs.

control- ???

May also have

Emergent properties-

Interfaces to other systems-

Sub-systems- Systems that operate separately from the main system

Different processes

Online– The application receives instructions and completes them eg. when surfing the net

Real time– The application needs to respond to requests in a certain amount of time, usually seconds eg. airplane controls

Batched– The application saves the requests and processes them at an off-peak time eg. overnight banking

Different systems

Open system– A system with input, it changes its behavior according to conditions outside its boundary

Closed system– A system with no input, it doesn’t interact with the enviroment

SDLC– System/software development life cycle, the process used to develop/upkeep a system/software

Cause and effect

One point of reference changing will cause a chain reaction where the system reshuffles to make everything work