2. What was difficult about it and how would you suggest it could be improved?
if it does not request words limitation and reference, it will be nice that we just write whatever we have understood.
3. Name three (3) things you learnt this term in COIS20025.
there are lots of things I learnt from this course.
first, how to start system analysis, what the fact finding is.
second, how to identify every business function
third, how to manage the system maintenance
4. What career are you working towards?
I wish I would work in system analysis, I believe I am better at doing configuring rather than programming
5. How will you be able to use the knowledge and skills learnt in this course in your future career?
I believe all I learnt in this course is practical. I can apply these knowledge into the future career. maybe these are only the tips of the iceberg, but they are at least my infrastructure of getting into a project.

Adaptive maintenance (Add new capabilities and enhancements)
• Systems don’t function in isolation
• Typically they may interact with operating systems, DBMS’s, GUI’s, network protocols, other external software packages, and various hardware platforms
• In the IT industry any or all of these may change over a very short period (typically six months)
• The process of assessing the effects of such “environmental changes” on a software system, and then modifying the system to cope with those changes is known as “adaptive maintenance”

Perfective maintenance (Improves efficiencies)
• Users and marketers are never satisfied
• Even if a system is wildly successful, someone will want new or enhanced features added to it
• Sometimes there will also be impetus to alter the way a certain component of the system works, or its interface¤
• The process of receiving suggestions and requests for such enhancements or modifications, evaluating their effects, and implementing them is called “perfective maintenance”

Preventive maintenance (Reduces the possibilities of future system failure)
• Sometimes changes are needed for entirely internal reasons
• Such changes have no direct discernible effect on the user, but lay the groundwork for easier maintenance in the future
• Alternatively, such changes may improve reliability, or provide a better basis for future development
• The process of planning such code reorganizations, implementing them, and testing to ensure that they have no adverse impact is known as “preventative maintenance”

Parallel operation
>With parallel operation, both the new and the old systems operate fully for a specified period
>Data is input to both systems, and results can be verified
>Cost is relatively high, because both systems operate for a period of time
>Risk is relatively low, because results can be verified and a backup option exists
>Method is impractical if the systems are dissimilar or cannot be supported together

Pilot operation
>With pilot operation, both the new and the old systems operate, but only at a selected location, called a pilot site
>The rest of the organization continues to use the old system
>Cost is relatively moderate, because only one location runs both systems
>Risk also is relatively moderate, because the new system is installed only at the pilot site and the risk of failure is reduced

Phased changeover
>With phased changeover, the system is implemented in stages, or modules across the organization
>Phased changeover gives part of the system to entire organization
>Cost is relatively moderate, because the system is implemented in stages, rather than all at once
>Risk also is relatively moderate, because the risk is limited to the module being implemented

Kendall, KE & Kendall, JE 2006, Systems analysis and design, 7th edn, Prentice Hall, New Jersey.

Mostafavi, H 1998, ‘performance effects of applying design patterns to a telecommunication system ’, (Online ProQuest).

Oestereich, B 2002, Developing software with UML, 2nd edn, Addison-Wesley, London.

Rob, MA 2006, ‘Dilemma between the structured and object-oriented approaches to systems analysis and design’, The journal of computer information systems, Vol.46, Iss.3, pp 32-43, (Online ProQuest).

Shelly, G, Chasman, T & Rosenblatt, H 2007, Systems analysis and design, 7th edn, Thomson Course Technology, Boston.

Sim, ER 1996, ‘An investigation into the effectiveness of object-oriented analysis’, (Online ProQuest).

Valacich, JS, George, JF & Hoffer, JA 2001, Essentials of Systems analysis and design, 2nd edn, Prentice Hall, New Jersey.

Whitten, JL, Bentley, LD & Dittman, KC 2001, Systems analysis and design methods, 5th edn, McGraw-Hill & Irwin, Boston.

The systems development life cycle (SDLC) can be defined as a process of understanding how an information system can support business needs or requirements of an organization, modeling the business processes, designing the systems components, and building the system. Both approaches to develop a system’s go through a sequence of four fundamental phases: planning, analysis, design, and implementation. Each of these phases also consists of a series of steps or activities that rely on some techniques to produce required deliverables. The traditional approach also called structured methodology is based on waterfall model. It adopts a formal step-by step approach to the SDLC phase and activities. Which means the activities of one phase must be completed before moving to the next phase. At the completion of each activity or phase, a document is produced that must be approved by the stakeholders before moving to the next activity or phase. The center of the structured approach is the process model and the tool used to present this model is the data flow diagram. DFD and their associated data dictionary contain information about the systems components that need be designed and ultimately built.
Another approach to SDLC is the object-oriented methodology. It is originated from the software engineering professionals who deal with systems development in various domains such as aerospace, business, and process control. OO approach follows an iterative and incremental approach to systems development. There are several phases: inception, elaboration, construction, and transition. In each increment, developers move through the activities of gathering requirements, analyzing the requirements, designing the system, implementing the design, and testing the system. It uses a set of diagramming techniques known as the unified modeling language (UML). It focuses on the three architectural views of a system: functional, static, and dynamic. The functional view describes the external behavior of the system from perspective of the user. Use-case diagrams are used to depict the functional view. The static view is described in terms of attributes, methods, classes, relationships and messages. The dynamic view is represented by sequence diagrams, collaboration diagrams, and statecharts. All diagrams are refined iteratively until the requirements of the IS is fully understood. Finally, the IS is developed through a combination of traditional relational database and object-oriented programming-rather than true object-oriented methodology for both programming and database.

Process Name Register members
Process Number 1
Purpose Register customer as members
Input Data Flow Apply membership
Output Data Flow confirm personal info, payment and membership card
Process description Customers apply for membership giving personal information and payment
Notes

Process Name Give payment
Process Number 2
Purpose Become a member by giving payment
Input Data Flow Give payment
Output Data Flow Confirm the payment
Process description Customers pay some fee to be a member for easy renting
Notes

2. Sampling
Sampling techniques can be systematic, stratified and random sampling. This technique can be used when using interviews or questionnaires. When finding about traditional and object-oriented approaches, it’s useless to send questionnaires to everyone such as administrative staff and other workers in an organization Etc. We can use sample of participants like managers, system analysis’s, software engineers Etc. Even we take the panel of managers; they can be sampled according to their subject area.

3. Research
Research is the best technique to find information about traditional and object-oriented approach. It can include the Internet, IT magazines, books, technical material; news about industry developments and designs, seminars, journal articles, blogs, wikis, professional meetings Etc. Internet is the most valuable resource as we can get access to libraries, universities and publishers around the world.

4. Observation
It’s important to observe current operating procedures because it gives a better understanding of the system procedures. We can observe a particular organization following the procedure in traditional or object-oriented approach. Therefore we can understand how the theory will apply practically in the real working environment.

5. Questionnaires and Surveys
Questionnaires also called surveys is a document containing a number of questions that can be sent to many individuals to obtain information. But I don’t recommend it as a good technique to find out about the traditional and object-oriented approach to system development. Because we need a standard and accurate description about these two approaches, but not the responses from other people. As well as questionnaires will lead to inaccurate and confusion from the people’s perspective against the actual standard approach.

* staff of PTW use different bits of software for storing types of data, therefore, data is stored in different formats;

* data could not be shared easily for analysis;

* info is inconsistent, incomplete and in many cases duplicated; and

*data is hard to be maintained and updated because of technical problems.

Further information need to be updated.