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. This topic is covered before students start work on the project. Project Management is a set of principles and tools for defining, planning, and executing, controlling, and completing a project.


 * 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:
 * 1) 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.
 * 2) 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.
 * 3) 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.
 * 4) 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.
 * **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** Product design
 * This is the time frame, created up by the systems analyst, in which s/he will have to complete the project.
 * Product **design**
 * 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 technical documentation**
 * 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:
 * 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?
 * 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.