3.9+Introduction+to+project+management

= =

All IT development requires a management method. Knowledge and understanding of the product development life cycle (PDLC) should be used as a framework to develop an IT solution for the internal assessment. It is recommended that this topic is covered before students start work on the project. IT concepts to address in this topic

Theoretical fundamentals
• Client, end-user, developer The client could be a business wanting to make work easier for their employees and therefore wish to invest in a system which replaces a paper-based system.

The end-user is the person who uses the information system directly or uses the information produced by the system.

The developer is the systems analyst which will evaluate the existing system, design the new one, develop it, and evaluate it.

[[image:systems_analyst.jpg]]
• Data collection techniques for content and product design, citing of sources

Typically, a great deal of information about the current system can be found in company documents - business plans, reports, manuals, correspondence, and systems documentation. The systems analyst can review these documents in the investigation and analysis phases to find out how the current system is designed and how it is supposed to operate.
 * Document review**

Systems analysts interview managers, employees, customers, suppliers and other people to gather information about business processes and problems and to collect ideas for improvement. In a structured intervuew, the analust asjs the same questions of each person. In an unstructured interview, the analyst might vary the questions.
 * Interview**

The systems analyst can use a paper or digital questionnaire to collect information from a large group of people. Questionnaires are convenient, and respondents can remain anonymous if desired.
 * Questionnaire**

images and vids later

(user trial) The systems analyst can watch and employee perform a task, see how people interact with one another, or observe whether procedures work as expected.
 * Observation**

• Role of testing and processes used Testing plays an important role in the systems life cycle as it determines whether or no the system works and if ultimately it is successful. Data can be tested in three ways: by inputting normal data; data which should be accepted if the system has been properly constructed. By inputting invalid data, data which is deemed invalid could be the number 1001, in an age box with a range of 0-130. Finally extreme data can be used to test the system. Extreme data consists of data on both extremes of the accepted range. In the example given above 0 and 130 would be considered extreme data. Testing usually occurs before a system is delivered to the client and after the system has been implemented with 'live data' (real data input by the users). If the system were to fail the testing phase, the analyst would have to re-research, re-analyse and re-design the system.

• Technical and end-user documentation (manuals)

For large custom systems, implementation includes end-user education and training, equipment replacement, file conversion, and careful monitoring of the new system for problems.

• End-user training During training, clerical and managerial end users learn to use the features of the new system effectively. They learn how to handle problems that may arise when they the th system. The training is often handled by end-user representatives from the project team rather than by technicians.

The product development life cycle (PDLC)
• Investigation of existing system(s) There are four main ways a system analyst can use to investigate existing systems:
 * Reading existing documentation: If the existing system is not a paper based system, the manufacturer of the existing software, was required to write technical documentation on how the system was built and how it works. This is to help any other system analysts in the future, who are hired to update the existing software, or create a new one.
 * Interview existing users: By interviewing existing user, the system analyst can ask detailed questions about how the system works and in what sections would the existing software benefit in being updated. An advantage over questionnaire answers is that the system analyst can adapt to each interviewee and can ask any new questions he/she thinks off.
 * Questionnaires: The system analyst can give out questionnaires about various issues regarding the existing software. One disadvantage is that employees can discard the questionnaires or not bother to properly read the instructions, thus errors can occur which make the system analyst's job harder.
 * Watching the existing software in use: the system analyst can see, first-hand, how the system is being used and whether necessary changes should be made when creating/updating the new system.

At some stage of business development, they are likely to feel the need of a computerized system to help and simplify their day to day tasks which would otherwise time consuming and hard to handle. Alternatively a business might already have a computerized system but is no longer effective, creating the need for a system update or a completely new system. An example of a system that would be set could be database system that would help keep track of student’s names, addresses, telephone numbers etc. More examples include:
 * Library database system
 * Online bank system

In order to have a successful system a business must first conduct a system analysis, also known as a system life cycle, illustrated by the image below:  Avoiding doing a system life cycle will often result in disappointment for the business as well as having the issue of not solving the problem originally presented. The system life cycle consists of various stages which will be explained in more detail below, these include:
 * Feasibility study
 * System analysis
 * System design
 * Programming a testing
 * Installation
 * Operation and maintenance
 * Termination and system upgrade

• Feasibility study A feasibility study encapsulates various topics which discuss whether or not it is possible to create the new system. The system analyst usually discusses if the proposed system is economically viable, if the technology exists to create the new system, and time it will take to plan, design and manufacture the new system.

• Requirements specification The requirements specification is a document produced by the system analyst which is created after all the primary and secondary data have been recorded and analysed. The requirements specification specifies what the new systems capability and limitations should be, and is used to evaluate whether or not the new system is deemed a success or a failure.

• Project schedule As the name suggests project schedule is the time frame, drawn up by the systems analyst, in which he will have to complete the new system.

• Product design When designing the new system, the system analyst needs to decide on the method of input used in the new system. There are two main ways in which data can be input:
 * Manually: Paper forms, or directly inputting data into an on-screen form.
 * Automatically: Using a bar-code scanner or a card scanner.

After deciding how the input system will work, the system analyst needs to draw up some prototypes of the input forms and present it to his client, which will then accept the prototype as it is or ask the systems analyst to make any changes the client deems necessary. After the input form has been created, the systems analyst then needs to create the system itself. The system should include data validation and verification methods, and the output methods, (on-screen or printed).

• Product development and technical documentation The documentation produced by the systems analyst consists of two documents:
 * User Documentation: User documentation is written to help the user of the new system work with the new system and how to fix any problems. User documentation usually contains FAQ (Frequently Asked Questions), minimum and recommended system requirements, how to use the system's features, any error messages which might appear and a troubleshooting guide.
 * Technical Documentation: Technical documentation is written to help other system analyst who at a later point in time might be hired to update the system. Technical documentation consists of: details of the hardware and software required, details of data structures, details of expected inputs, data validation/verification methods, details of how data is processed, diagrams of how the data moves through the system and finally flowcharts describing how the system works.

• Client and end-user evaluation The end-user evaluation consists of evaluating how efficient, how easy to use and if the system is appropriate for the business and if it meets the standards. Two ways in which the system can be evaluated are: The evaluation can be made through the use of questionnaires, interviews and by observing the users in action. The data can then be analysed and evaluated to help in the improvement of the system.
 * Checking against the requirements specification to check if the system does everything it was set out to do in the beginning.
 * Checking the users' response. Is the system easy to use? Does it make work easier? Can any improvements be made?

Practical techniques
• Appropriate design techniques • Data capture • Product testing and debugging

[]