Application Development Tools

IS202

Prof Greg Foster

Room 006, Hamilton Building
g.foster@ru.ac.za
 Module Objectives
• Implementation phase.
• C# and the .NET framework.
• Fundamental programming concepts.
• Using the OO programming approach.
• Understand the key processes related to building
functioning applications
• Appreciate the complexity of application
development.
 Module Outcomes
• Demonstrate an understanding of:
– where program development fits into the SDLC
– OO concepts, characteristics and terminology
– the skill required to program in a high-level
development environment
• Develop the skills to:
– undertake basic program development using C# in
the .NET framework
 Expectations
• Attend classes.
• Engage with the module.
• Self study.
• Complete practical exercises honestly
– essential practice to reinforce the concepts
 Resources
• Text Book:
– Bell and Parr (2009) C# for Students, Addison Wesley

• Other resources on ADT website as needed.

• ADT website for all module
related material:
– lecture slides
– practicals
– extra material
 Topics of Discussion
• System Development Life Cycle
• Program Development Life Cycle
Systems Development Life Cycle
 Implementation Phase
• What is the purpose of this phase?
• What are the inputs to this phase?
• What are the outputs to this phase?
• What activities are performed during this
phase?
• To what extent does the end-user get
involved?
 Purpose
• A number of tasks have to be completed
before the system is installed and ready to
operate.
• “…includes hardware acquisition, software
development or acquisition, user preparation,
hiring and training of personnel, site and data
preparation, installing, testing, start-up and
user acceptance”
Stair & Reynolds (2003:577)
 Inputs
• Analysis & Design Phases:
– analysts would have documented the user requirements for the
system during the Analysis Phase.
– would have documented an overview of the system.
– also constructed an Entity Relationship Diagram and Activity
Hierarchy Diagram - use these to construct the tables and
relationships if developing the system.
– OO Approach
• UML – use case, class, interaction, state, activity …
– if purchasing off the shelf, use to decide if system can fulfil
needs.
– if constructing the system, construct the screens/forms and
reports based on the specifications drawn up during the Design
Phase.
 Outputs
• “Live system”
– running system that meets the user requirements.
– should have as few bugs as possible.

• Documentation
– technical
– user manual
 Activities
• Hardware Acquisition – Obtaining the components of the information system.
• Software Acquisition or Construction – Need to determine if going to purchase
software off the shelf or going to construct it.
• User Preparation – Changing mindsets – Getting people to realize new system.
• Personnel – Decide if new personnel are required – Do existing employees need
additional training.
• Site and Data Preparation – Preparation of the location of the new system, and, if
necessary, converting manual files into computer files.
• Installation – Setting up the equipment.
• Testing – Testing various aspects of the system.
• Start-up – Making the tested system operational.
• User Acceptance – Handover to client.
• Post-Implementation Evaluation – Assess the overall quality of the information
system.
 End-User Involvement
• A strong correlation exists between successful
systems and well-trained users.
• End-User is involved in:
– training
– user documentation
– systems testing
– post-implementation evaluation
Program Development Life Cycle
 Analyse Problem
• Review program specification package:
– the programmer reviews the package, which identifies the input,
output, processing and data requirements for each program. It also
shows relationships among programs.
– by thoroughly reviewing these deliverables, the programmer
understands the nature and requirements of each program.
• Meet with analysts and users:
– enables the programmer to understand the purpose of the program
from the users’ perspective.
– programmer may wish to recommend a change to some aspect of the
program. If this is the case, they discuss it with the analysts and users.
– programmer MUST NOT change a requirement without consulting with
analysts and users.
• Identify & review program’s input, output and processing
components.
 Design Programs
• Devise a solution algorithm:
– a graphical or written description of the HOW
– Design Tools
• Program flowchart
– graphical representation of relationships
– flowcharting software (e.g. Visio)
• Pseudo code
– written representation of program logic
– use indentation to depict control structures

• Test the solution algorithm

– identifying errors in logic is easier at this stage of
the PDLC than later.
 Code Programs
• Translate the solution algorithm into a
programming language.
• Enter the programming code into the
computer.
• Each language has its own syntax.
• Should document code as you enter it into the
computer
– use global and internal comments.
 Test Programs
• Thorough testing is very important
– decision making may depend on use of program and
its outputs

• Users should assist in development of test data.

• Looking for bugs/errors (debugging)
– syntax
– logic
– run-time
 Formalise Solution
• Review the program code
– look for dead/redundant code & remove it.

• Review all the documentation

– all documentation should be complete &
accurate.
 Maintain Programs
• Once implemented, it may be discovered that
the program needs to be changed in order to:
– correct errors
– add enhancements

• Starts another iteration of the PDLC!

 What you need to do next…
• Textbook – Bell & Parr:
– read Preface & Chapter 1
– practice some of the given examples
– try the self-test questions
– visit the companion web site:
http://www.mikeparr.info/csharp1st/csabout.html

• Read ahead to Chapter 2