System implementation
October 30, 2007
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting and have a nice day!
Issues involved in system implementation
Testing is one aspect of system implementation, this involves various other issues. The programmers have to test the individual programs. This is called unit testing. It validates the internal code of a program. This may involve
-
Desk checking is a manual walkthrough of the program, checking code against the requirements specifications.
-
It is also concerned with checking that standards have been adhered to as well as identifying opportunities for syntactical and structural improvements.
-
Compiling: A clean compilation is required.
-
Test data: Test plans are prepared and the results compared with predicted test results. Test data should be manually compiled and the results produced by the system compared with appropriate clerical figures or the current computer system outputs.
-
Testing the interfaces between tested programmes: Each program should be tested with the programs with which it receives or passes data.
Integration testing should also be done; this is concerned with validating the operations of a suite of inter-connected programmes. It seeks to test that a logical subsystem is working correctly and that data is passed properly between parts of the subsystem.
System integration should also be done; it seeks to ensure that the sub-systems work properly together. This testing is performed against a specification and should pass through.
-
Single run i.e. testing a system over a single pass of test data.
-
Cyclic tests: i.e. involves testing a system over several cycles of processing thus ensures that it correctly deals with end of day, end of month and end of year routines.
-
Volume tests: This test tries to see how the system copes with agreed volume and possible overloads i.e. stress testing.
-
Clerical tests: This involves testing all aspects of the interface between the user and the system.
User acceptance testing is another kind of testing that is organized and performed by users. It is concerned with proving to their satisfaction, that the delivered system meets the specifications.
Testing is a time consuming activity and the automated aids to assist in production of test data should be encouraged e.g. data dictionary.
File conversion is another issue that arises in system implementation. This occurs in two levels i.e. if the current files are being held in a computer or they are manual.
If they are in computer, then it should be possible to move data to the target hub, but certain routines should be written such as stripping off control characters or transacting fields to modify the data format after conversion. The programmes carrying out this conversion have to be tested.
Data entry programs also have to be written for data that is to be collected for the first time. The designer may be able to use data input routines of the proposed system for entering current information into the computer.
A special file creation program has to be written and tested so as to capture old historical data that can’t be captured using the current programs.
Documentation is also another aspect of system implementation. This is a constant and continuous task in system development. The type of documentation that has to be produced is
-
Training documentation, this documentation will typically set objectives, explain concepts and commands to examine whether the objectives have been achieved. Such documentation may use conventional media and methods such as handouts, lectures or computer based training. This documentation is concerned with two principle tasks.
-
To ease the transition from the current system to its successor.
-
To provide detailed tuition in the operations of the proposed system.
-
-
User documentation. This materials concentrates on issues that concern the user most i.e. functional and errors, and information on how to get started. User manual should be a reference document and not a learning document. It should reflect the vocabulary and expertise of a variety of users involved in the system.
-
Operational documentation: this documentation describes the normal operating procedures of the system and how users can respond to errors.
Training is also another aspect of system implementation. It covers retraining of current staff and recruitment of new personnel. Retraining will require planning and coordination.
-
Setting objectives for training will suggest ways of delivering the training. It can be lectures; computer based training, on-job training e.t.c. Once the materials have been delivered, the attainment of the trainee and the effectiveness of the training methods can be assessed.
The final aspect of system implementation is the implementation strategies i.e. the changeover from the old to the new. These strategies are:
-
Parallel Changeover, in this method the old and the new system are run simultaneously for an agreed period of time and the two systems are compared. Parallel method causes large administrative overloads, although the method can be said to be “fail safe”. This method has another problem in that users tend to rely in existing procedures so problems of the new system are not discovered until the old system is phased out.
Direct Changeover, in this method the final cutoff date is set and when it reaches, the old system is done away with, the new one is implemented. In this method, there is roof “fail safe” system but it doesn’t cost much in cheaper than parallel.
Post Implementation Review
This phase provides the opportunity to review the conduct of the project i.e. achievements, failures, surprises and assessment, all these provide experience that can be used in the future developments. It is concerned with user satisfaction and also the way the project was conducted. The quality of the delivered system and its documentation and training can be monitored through:
-
Failure rates
-
Calls to Helpdesk
-
User satisfaction survey
-
Change request and the time taken to implement them.
-
Statistics concerning the use of the system.
-
At some stage, a review of the system will be done to ensure it conforms to the requirements set out at the feasibility stage and the costs have not exceeded those predicted.
-
There are bound to be some changes necessary and some data processing staff may be set aside for maintenance, which is aimed at ensuring continued efficient running of the system.
-
Some changes will be due to technological advances, changes in the organization or its environment or new user requirements or even correction of errors.
Criteria for evaluating the effectiveness of an implemented system
Efficiency of a system is not the same as effectiveness of the system. Effectiveness focuses on business goals. The methods or criteria for measuring effectiveness of a system are:
Customer satisfaction, this could be done through questionnaires or other survey methods. Customer satisfaction can be used especially in systems that were primarily designed for customers. This can be evidenced by retention of old customers and attracting new customers.
Staff morale (staff motivation analysis), this criteria can help us identify what has happened to users as a by product of implementation of the new system.
Cycle time, this takes into consideration the length of time that it takes to accomplish a task. Faster cycle time may mean that the system is well accepted.
Degree of use, this is used to evaluate the system, in that how many potential users or customers use the system.
Meeting the business objectives i.e. the degree to which the system actually supports the strategic business goals.
Structured techniques supported by CASE tools
October 30, 2007
Structured techniques supported by CASE tools.
Structured techniques are ways in which large and complex systems can be developed to be effective, usable, reliable and maintainable.
Traditionally systems which were developed concentrated on aspects of effectiveness, usability and reliability, thus the systems were hard to maintain. Thus structured techniques were developed to help make /develop systems which are easy to maintain.
A structured technique lays its foundation on the fact that:
-
A well designed system will need few corrections.
-
Its approach will help develop more reliable and maintainable systems.
-
The system characteristics should go hand in hand with the making systems easier to modify.
Structured techniques have the following principles.
In order to better manage the development process, large and complex systems should be broken down into phases and those phases, further broken down to smaller, more handled tasks.
We should use graphics to illustrate ideas whenever possible since graphics can often help or make it easier to understand. The commonly used graphics are:
-
Data Flow Diagram (DFD)
-
Entity Model (ERD)
-
Entity life Cycle (ELH)
We should always keep a written record of the project and tasks done. Documentation should be an integral part of SDLC rather than a follow up. Documentation helps outsiders, newcomers and employee/user of the organization to understand the system. It also helps in training the users.
We should use diagrams of the finished system plan to uncover errors before they are incorporated into the physical end product. In that a system still on paper is easier and cheaper to change than a final finished product, thus we should begin the validation process right from the feasibility study.
Case tools helps in making the structured techniques easy to implement. They help to automate the process of diagramming the function of the system.
Text editors also help in writing the documentation of the system.
Tools like test generators, comparators are used to make the testing process easy to handle.
Prototyping with 4GL(Generation Language)
Prototyping is the process of developing a working abbreviated version of the finished end product so as to enable the user to see what the finished product will look like.
4GLs are languages that help develop a system easily and quickly. A user only tells it what is to be done, and it writes and generates the code automatically.
Thus prototyping with 4GLs is the process of developing a prototype easily, quickly and cheaply. 4GLs can easily incorporate new user requirements and provide quick feedback when executed.
They enhance user involvement because user involvement is more or less continuous throughout the development process.
Addressing the following problems with a combination of structured techniques and prototyping
Problems of operational understanding
These problems may stem from the inability of users and management to comprehend the workings of the system. To solve this problem you would use either methods or ways.
You would need to break down the system operational process to small functional tasks which will be easier to explain and understand. In situations where the explanation is difficult you would use diagrams to explain your point e.g. using DFD to diagram a particular operational task.
You would also ensure in the documentation of the system you will not use jargons but simple English statements supported by diagrams.
Problems in fulfilling user requirements
This problem would either stem from unclear answers from users. To solve this problem I would use prototyping so as to gather user requirement as much as I can. I would adopt either a throwaway or evolutionary prototyping or I would work hand in hand with the users explain any of their questions and documenting their comments.
Structural techniques would also come in handy especially when gathering the requirements. I would diagram the functions of the new system and I would only adopt them in the documentation
REFERENCES
Modern Structured Analysis (Yourdon Press Computing Series)
Structured Systems Analysis: Tools and Techniques. (Prentice-Hall Software Series)
Practical Guide to Structured Systems Design (2nd Edition)
Managing the Structured Techniques (Yourdon Press Computing Series)
Introduction to Systems Analysis & Design: A Structured Approach
Practical Business Systems Development Using Ssadm: A Complete Tutorial Guide
Systems development methodology
October 30, 2007
A methodology can be described as a collection of procedures, techniques, tools and documentation aids which will help the system development. A methodology can thus be said to have various features. These features can be categorized into technical model and managerial model.
A methodology needs to have a technical model. This model includes features like the tools, processes and procedures. A methodology needs to have tools which will help the developers in the process of developing an Information System. These tools help in every phase or sub phase involved in the methodology e.g. CASE tools, project management tools, Drawing tools, Data dictionary e.t.c.
A methodology also needs to have a technique. Technique help to verify and expound on the methodology, thus they enable the phase and sub phase of methodology to be carried out according to the methodology’s principle. Technique acts as guides of methodology’s phase. Techniques address different parts (phases) of a methodology. A methodology can have many techniques. Techniques also enable easy understanding of what the methodology requires e.g. Decision trees/tables, Entity Life Cycle, Structured diagrams, normalization e.t.c.
A methodology also needs to have a philosophy, in that it needs to have the underlying theories and assumptions that the authors of the methodology believe in. This feature helps to shape and guide the development of an Information System. It also enables the understanding of the methodology.
A methodology also has a managerial model. This feature is that of the development structure, in that a methodology needs to have a development structure that;
-
Identifies the phases, sub phases, steps and tasks to be done in the methodology.
-
Identifies the outputs to be produced and under which circumstances they should be produced.
-
Constraints to be applied and people to be involved. This feature provides for the development process to be really managed and controlled.
The rationale for writing a methodology
A better end product: In that the methodology should improve the end product of a development process i.e. a better I.S.
A better development process: In that the methodology should provide improved management and project control so that the organization can gain from the benefits that accrue from a tightly controlled development process.
A standardized process in that people take up a methodology that can provide a common approach through out the organization so that they gain from the benefits of standardization mainly;
-
Better integration of projects or systems.
-
A base of common knowledge and experience is achieved.
Practical issues to be considered when selecting a methodology?
The practical issues are budget constraints; the organization should consider the cost associated with the methodology e.g. training, hardware, software costs, CASE tools, consultancy e.t.c.
Dependency on automated tools: in that the organization should look to see if the methodology depends on these tools and if the organization is happy with that or not.
Learning curve is another issue that the organization should consider.
Aids to future developments: if the methodology is feasible and can be adapted as technology changes.
Relevance to the application:
Human &Organizational factors leading to project failure
October 30, 2007
In traditional systems the technological failure was the major cause of failures in business data processing. Today, the failures are mainly caused by human and organizational problems.
Human problems are issues that are caused or raised by users and other people involved in the project that might cause the projects to fail. Some of these human problems are:
Lack of Co-operation in that the users may sabotage the project by not co-operating with the developers or some objectives that were not agreed upon by management may be introduced.
Poor training is also another human issue that may cause a project to fail. If the users are not properly trained on how to use the system, the project in turn will not be helpful as envisioned. Also the various people involved in the project may need to be sensitized on their roles e.g. sponsors, users e.t.c. so that they can know their responsibilities in the project.
Poor communication is also another human issue that can cause projects to fail. If the developers and the users of the system are not communicating then the project is doomed to fail. Proper channels of communication in a project must be clearly defined.
Lack of involvement of those needed in the project can cause it to fail, in that if the developers do not involve the users or the management in the project then chances are high that the project can fail.
Not all failures are caused by human factors; some failures are due to organizational factors like;
Lack of management support, the management may view the system or project as an issue for users and thus they may not get involved except when allocating resources, also projects need constant involvement by management and this may cause the manager to see it as a time wasting issue thus they may not get involved.
Lack of resources is another organizational issue that might cause projects to fail, in that the management may stop allocating some resources to the project midway. E.g. managers or money e.t.c. thus will cause the project to fail.
Lack of planning or poor planning may cause the project to fail in some way, in that the time, money allocated to the project might be so little for the project to work with hence it fails.
Lack of control in the project may cause the whole project to fail, in that the organization or the project manager may not put enough checks and review meetings to monitor and control the project.
External influences may also cause the project to fail in that factors such as social, political, economic, technical and legal issues may influence the project negatively and hence fail. Most projects often raise political and social issues and thus the management need to ensure that the project gets the political support needed and the local community support.
REFERENCES
Information Technology Project Management, Fourth Edition
Project Management: A Systems Approach to Planning, Scheduling, and Controlling
The Fast Forward MBA in Project Management, Second Edition
The Art of Project Management (Theory in Practice (O’Reilly))
Project Management: A Managerial Approach
Fundamentals of Technology Project Management
IT Project Management: On Track from Start to Finish, Second Edition (Certification Press)
Requirements analysis
October 30, 2007
Requirements Analysis (Elicitation)
After initial feasibility study, the first major stage of requirements engineering process is requirements analysis or elicitation. The technical software development staff works with users to find out
-
what functions the system should provide
-
required performance of the system
-
hardware constraints etc
This stage is depended on for user acceptance i.e. how well the system meets the users needs and supports the work to be automated.
Requirements Analysis is a difficult process because
-
Users often don’t really know what they want from the computer system.
-
Different users have different requirements and they express this in different ways.
-
Since analysis takes place in an organizational context, political factors in organizations may influence requirements of the system.
-
The economic and business environment in which analysis takes place is dynamic e.g. new requirements may emerge from users who were not originally consulted.
The process of gaining these requirements is iterative with continual feedback from each activity to other activities. The process activities are:
-
Domain understanding: Analysts must develop their understanding of the application domain e.g. If a system is for a supermarket, the Analyst finds out all he/she can about supermarkets.
-
Requirement collection: this is the process of interacting with users in the system to discover their requirements
-
Classification: This activity takes the unstructured collection of requirements and organizes them into coherent clusters.
-
Conflict Resolution: This involves finding and resolving conflicting requirements.
-
Privatization: This stage involves interaction with stakeholders to discover the most important requirements.
-
Requirements validation: The identified requirements are checked to discover if they are complete, consistent and in accordance with what you really want from the system.
Requirements Definition:
A system requirements definition is an abstract description of functions/services which the system should provide and the constraints under which the system must operate. It should only specify the external behaviour of the system it should not be concerned with system design characteristics.
The requirements should not be defined using an implementation model i.e. the definition should be written in such a way it’s understandable to users.
The requirements may either be functional or non functional
The functional requirements should be
-
Consistent: The requirements should not have contradictory definitions.
-
Complete: i.e. all functions required by the user should be defined.
Requirements specification:
This adds further information to the requirement definition. The requirements specification is usually presented with the system models developed during requirement Analysis.
The specification and the model should describe the system to be designed and implemented.
It should include all the necessary information about what the system must do and all the constraints on its operations.
Since the use of natural language on this document might bring problems e.g. misunderstanding because of ambiguity of natural language words, one can use alternatives such as
Structured natural language
This is a form of structured definition. It depends on using standard forms or templates to express the requirements specification
Design Description Language
This approach uses programming language but with more abstract features by defining an operational model of the system.
Requirements Specification Languages
These are special purpose languages that can be used to express software requirements such as PSL/PSA, RSL.
Graphical notations
This notations can be used for analysis and requirements specification eg SADT.
Mathematical specification:
These are mathematical formulas that are formal mathematical concepts such as finite state machines.
A requirement specification should have traceability i.e. the case of finding related requirement to achieve traceability one can:
-
have all requirements assigned unique number
-
Requirements should explicitly identify related requirements by referring to their number.
-
Each requirement document should contain a cross reference matrix showing related requirements.
Requirements Engineering
October 30, 2007
REQUIREMENTS ENGINEERING
Requirements engineering is the process of establishing what the new system should do. The requirements may be functional requirement or non functional requirement.
Functional requirement is one that describes the systems function or service while non functional requirement is a constraint placed on a system (e.g. Response time) or the development process.
These requirements can be said to evolve in 3 stages from requirements definition, to requirement specification and software specification.
-
Requirements Definition:
This is a high level abstract description of requirements. It can also be said to be a statement in natural language plus diagrams of what services the system is expected to provide and constraints under which it must operate.
-
Requirement specification:
This is a structured document which sets out the systems functions in detail i.e. detailed description of what the system should do.
-
Software specification
This is an abstract description of the software which is a basis for design and implementation. This is a document for the design team used for system development.
The requirements engineering process should normally involve writing a requirements definition then expanding this to requirements specification.
-
Different levels of system specification are useful because they communicate information about the system to different types of users.
-
Requirements information should be targeted to managerial level, it must be understandable by both client and contractor management who will not have a detailed technical knowledge of the system.
-
The requirement specification should be targeted at senior technical level staff and project managers.
-
Software specification is an implementation oriented document. It should be written for software engineers who will be involved in developing the system.
Requirements Engineering Process:
This process is the set of activities that lead to the production of the requirements definition and requirements specification. The 4 principle stages are:
-
Feasibility study:
This study should be relatively cheap and quick. It is an estimate of whether the identified user needs may be satisfied using current software and hardware technologies.
The study will decide whether the system (proposed system) will be cost effective from a business point of view and if it can be developed with the existing budgetary constraints.
The result of this study should form the decision of whether to go ahead with a more detailed analysis.
-
Requirements Analysis:
This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis and so on.
It may involve development of system models to help the analyst understand the system to be specified.
-
Requirements definition:
This is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. This should accurately reflect what the user wants. The document must be written so that it can be understood by end-user and system customer.
-
Requirements Specification:
A detailed and precise description of the system requirements is set out to act as a basis for a contract between client and the developer. During the development of the requirements specification, errors in requirements definition are discovered and they must be corrected.
The above activities are carried out in iteration i.e. the requirements analysis continues during definition and specification and new requirements arise during the process, thus the documents are suspect to frequent changes and should be placed under the control of a configuration management system.
Software Requirements Document:
This document is a combination of software definition and software specification. It is not a design document and it should set out what the system should do without specifying how it should be done.
-
The requirements should be stated so that there is traceability between these requirements and the final system design i.e. it should be possible to take each specified requirement and map it on to the part of the system design that implements that requirement.
-
The requirements set out on this document ought to be complete and consistent. All system functions should be specified and requirements should not conflict.
-
The document should be structured so that it can be easy to change: it should be split into chapters and sections.
-
Cross references from one requirement to another should be kept to a minimum.
Software requirement document should satisfy the following:
-
It should only specify external system behaviour
-
It should be easy to change
-
It should specify constraints on the implementation
-
It should record forethought about the lifecycle of the system.
-
It should characterize acceptable responses to undesired results.
The structure for a requirements document is
Introduction
-
should describe the need for the system briefly
-
its functions and how it will work with other systems briefly
-
it should describe how the system fits into the organization’s business or strategic objectives.
Functional Requirements:
Describe the functions the system is to achieve. The description should use diagrams, natural languages and other notations understandable by users.
Non Functional requirements:
It should define constraints imposed on the software and restrictions imposed on the designer should be described and related to functional requirements. It might include memory requirements, response time, and data representation.
System Models:
The document should set out one or more system models, showing the relationship between the system components and the system and its environment. This might include object models, dataflow models, and semantic data models.
System Evolution:
This should describe the fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs etc.
Requirements specification:
This should describe the functional requirements in more detail and also add more detail to non-functional requirements.
Glossary: This defines the technical terms used in the document.
Prototyping
October 25, 2007
Prototyping!
Prototype is the model of a business that serves as a model for future development.
A prototype of a business system may be used to demonstrate its initial performance and the system may be modified to achieve its objective.
A prototype may be used to
-
select the best design from a number of designs
-
to test a chosen design under different environmental conditions
-
To verify that the users needs have been met.
-
Verify that the design meets the specifications
Generally prototyping is not advisable for batch systems or one that produces standard hard copy report using a large institutional database. Online interactive systems favour prototyping e.g. advisable in decision support system.
There are 3 approaches to prototyping according to logical structured design methodology.
-
1st Approach:
In this approach a series of menus and screens are built and the user processes transaction as he would do in a live system. If it’s acceptable the prototype is further developed. This system is best when the user requirements are well defined and it does not support logic or a database.
-
2nd Approach:
This is building of a throw away version for user trials. It incorporates system logic in addition to menus screen and databases. This is the best used in large complex projects where user’s requirements are not well defined. The prototype software is unlikely to have performances and facilities for implementation as a physical system
-
3rd Approach
This is the second approach but the prototyping software is intended to form the final system. This becomes the pilot for a project with phased implementation plan.
Advantages of prototyping:
-
Enable the user to visualize how the system will work.
-
An accurate user requirement is met by or in that if one does not want a certain system or if it has a weakness one can change.
-
Increases productivity
-
Saves time and money on system analysis.
-
Improves or reduces backlogs by improving turn-around time in finding system solutions.
-
New user requirements can evolve
-
Increase productivity
-
Saves time and costs by ensuring they are implementing the correct design.
-
Heavy user involvement less resentment
-
Early training
-
User feel confident supporting a system they have already tested.
Output Design
October 25, 2007
Output Design
In most systems, the following reports may be present:
-
On Demand Reports: These are reports that are produced to satisfy adhoc queries about the data stored in the systems. Users may use report generators to define the fields they want and the criteria for selection and the order of printing.
-
Report generators relieve the analyst of the task of specifying all possible requirements in advance and it also helps to allow the reporting system to change and reflect new user requirements.
-
Summary Reports: These are reports produced at specific intervals that reflect a summary of detailed listing of individual reports.
-
Exception Reports: These are reports that show date on information that is extraordinary or not within the accepted norms. Their purpose is to prompt some action. They thus are used in decision making.
-
Internal Reports: These are reports that are not used outside the organization. They usually contain detailed internal information.
-
External Reports: These are reports that are used outside the organization such as invoices, etc
-
Archival Reports: These are reports which are produced when the appropriate data is no longer required by the system.
REFERENCES:
Designing Interfaces: Patterns for Effective Interaction Design
Prioritizing Web Usability (VOICES)
Designing Web Usability : The Practice of Simplicity
The Elements of User Experience: User-Centered Design for the Web
Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests
Designing Interfaces: Patterns for Effective Interaction Design
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives
System development Lifecycle (SDLC)
October 25, 2007
The System Development Life Cycles!
The waterfall model also knows as the SDLC was originally published in 1970 by W. Royce. This is a step by step way of developing projects.
The waterfall model is broken down into stages and each stage is completed before proceeding to the next.
Stages of the waterfall model
In the waterfall model there are seven stages of the development of a project.
-
Problem Definition
In this stage the users or the manager realizes that the Information system is no longer reflective of the existing business which may have expanded or that they need to computerize their manual operations.
This problem could come about due to complaints by users or by formal review of the Information system.
An Analyst examines whether there is a problem and then studies the problem in depth, and an authorization to conduct a feasibility study is given. This authorization is the output or the deliverable at this stage. Thus users, managers and Analyst are used in this stage.
-
Feasibility Study:
In this stage the Analyst examines whether a new system is feasible. He assesses the magnitude of this problem and decides the scope of the project. He examines the problem of the current system and what will be required of the new system.
Economical, technical and operational feasibilities are done. The output is a feasibility study report.
Tools used in this stage are fact gathering Techniques and Estimation Techniques. Users and the Analyst plus management are heavily involved.
-
Analysis
In this stage detailed investigation are done about the current system. This include
-
reading existing documentation
-
Interviewing the users
-
Observing work being done
-
Observing current procedures
-
Questionnaires
After gathering the needed facts about the existing system the Analyst diagrams the current system and then considers the functions of the new system. A new set of diagrams which incorporate new functions is made. A prototype is also generated using these gathered facts to help uncertain users know what they want in the new system. Thus it helps to reveal new requirements. The Analysts makes a problem specification using fact gathering tools, prototypes, DFD, Data models process specifically etc. Users are involved so is the Analysts
-
Design:
In this stage basically the hardware and software are ordered so that they can arrive in time for construction.
Functional diagrams are translated into hierarchial diagrams by the analyst so as to identify what programs are needed and how they relate to one another. The analyst decides on the program structure, program interface and the hierarchy in which programs will be arranged.
The Analyst ensures quality designs, incorporates security measures, designs easy to use input forms, output reports interfaces.
The Database designer fulfills the file requirements. The output is a design specification.
Tools used are DFD, Data Dictionary, Data models, prototypes, system flowcharts: The personnel involved are users, Analysts, Database Designer.
-
Construction
The computer environment is prepared, the programs to be written are done and they are tested, user documentation and training manuals are developed.
Computer environment being prepared means electrical wires, network cables are installed, furniture, air conditioning are in place. The computers are installed and tested.
Programs are written per the program and design specifications. The programs are tested using walk through and group reviews. The Analyst supervises the writing of training manuals and user documentations. User documentation includes user manuals, user quick reference guides, on-screen help etc.
People involved are programmers and analysts. Tools used are structured, walkthroughs, CASE tools etc
6. Conversion
The Analyst helps the staff to convert from the old system to the new one. The Analysts oversees the transfer of data files electronically to the new system.
Conversion can be done in various ways
-
-
Phase Conversion
-
Parallel Conversion
-
Direct Conversion
- Pilot Conversion
-
Output is that the system is operational and the tools used are automated data transfer programs.
7. Maintenance:
System modifications are made to the system after the system is operational. Maintenance can be
(1) Perfective (3) preventive
(2) Corrective (4) adaptive
The traditional SDLC has a number of good features. It has been well tried and tested. However this method has been known to have several drawbacks.
Some of the drawbacks of SDLC are user dissatisfaction. SDLC assumes that the user already knows all their requirements thus they expect the users to tell them their requirements and once documented the requirements should remain unchanged, thus they develop the system with these requirements only to find that when the system is implemented, it does not provide for their need or their changed requirements, hence they become dissatisfied with the system.
Failure to meet the needs of the management in that the system developed with the approach are mainly operational processing systems such as payroll, invoicing which deals with low level operational tasks, thus ignoring the information needs of the tactical and top management, that they require to make decisions e.g. which products to stop selling e.t.c.
Unambitious system design, in that the systems developed by this approach often tend to computerize the manual operational tasks like invoicing, thus they tend to come up with systems design that are similar to the existing manual process.
Application backlog, this approach has many phases with sub phases, It may take many weeks to complete a phase, thus the overall development time of a single project may be months and if there are other system waiting to be developed using this process, it may cause a backlog.
Maintenance workload since the firm may have many systems to develop, the development is often quick and ‘dirty’ so as to make the delivery date, thus brings about systems which take a huge effort to maintain.
Problems with documentation, this approach provides for documentation of the implementation process which is very ideal, but the notation of the documentation is towards the computer person in that the documentation is highly technical and not easy to understand by the user.
System analysis: Interview
October 25, 2007
Interviews:
This is the systematic collection of facts relating to a proposed system through interviews. An analysis information is gathered from the
(i) Primary source: i.e. the users of the system or those who have first hand knowledge about how the system operates.
(ii) Secondary source: i.e. This is the information found in manuals, reports and system documentation.
Three session interviews:
As a rule of thumb, at least 3 interviews are required. These are:
(a) Initial session: This is a short non-structured interview in which the analyst describes the work to be done, clarifies his/her role and asks the users for his/her ideas. This session provides the analyst with facts and opinions necessary for framing questions in the second session.
(b) Fact-Finding session: This is longer and more structured than the initial session. The purpose is to determine specific system functions and performances levels derived by the user.
(c) Summary Session: This represents the non structured reporting session rather than interview. The purpose of these sessions is to summarize the results of the fact finding interview and to determine whether the user agrees with the analyst’s findings.
Structured Interviews:
These are interviews which ask specific pre-determined questions. Structured interviews consist of series of close-ended questions i.e. questions which restrict users reply to a predetermined set of responses. They have multiple choices
Non-structure Interviews:
These are interviews which allow a user to express facts and feelings. Non structured interviews consist of a series of open-ended questions. These questions lead to a variety of user responses.
