Introduction
The Systems Development Process (Overview)
Project Selection and sources of Projects
Course Overview
This is an introductory resource for systems analysis, design, and implementation of information systems. Systems analysis, design, and implementation are, in the broadest sense, the processes used by professionals to develop or maintain information systems.
Objective
To give an understanding of the methodologies and the applicability of the steps involved in analysing, designing, testing and implementing a computer / information system.
Projects do not succeed by chance
Successful IT projects follow systematic “analysis and design” process
Introduction
Earlier applications that used computers were business applications, such as keeping records of transactions, Airline reservations etc.
Computers are now becoming part of virtually every activity in an organization.
What Information Systems Can Do
Largest commercial port
30,000 ocean going vessels & 150,000 river boats per year
300 million tons of cargo per year
$35 billion in revenue per year
Fierce competition from other ports
Develop plan 2010 - $23 billion to be spent on developing IS
Port business is very dependent on quick information exchange between the companies involved
Large oil companies, freight forwarders, custom brokers need to get there IS connected with that of the port for fast exchange of cargo manifests, import permits etc.
All such documents in digital form
Similar methods adopted by Port of Singapore
Processing time reduced from 2-4 days to 15 minutes
Keeping a ship in dock for an extra day costs its owners dearly, amounting to millions of dollars
Singapore port has cut down it’s processing staff by 75%
Volume of shipment has doubled
Economies of EDI benefits both customers & the port
Container handling companies can prepare the appropriate freight just in time for truck arrival
The times that trucks spend in the port has been cut down to 15 to 20 minutes from a previous 1-2 hours
Even a small company now stops at the port 50-55 times a day
Vessel Traffic Management System – provides traffic controllers with a complete overview of traffic in the port 24 hrs. a day
Maintains historic data too for seagoing ships
Helps managers to control current operations as well as plan for the future
Gets help from Rotterdam’s Erasmus University
Will create many job opportunities in the IT sector
Definition
SA & D covers the entire systems development process from planning all the way through implementation, maintenance, and evolution.
It is a process that includes all activities performed to produce an automated IS.
Justification of SA & D
What is a System?
A System is set of interrelated components, working together for a common purpose.
A generic systems model consists of six components – inputs, outputs, controls, feedback, and boundary.
Using predetermined controls, a system accepts inputs at its boundary, processes them into outputs, and provides a feedback mechanism for taking any necessary corrective action.
Cont…
The internal control subsystem either directly implements change to the IS or notifies the end-user that the system is not functioning properly.
Controls ensure that input data is valid before its processed, that file and database data are protected against unauthorised access and update, that recovery procedures are available for a system catastrophe, that output information is disseminated to proper end-users, and that other relevant conditions are met.
System Boundary
A boundary (scope) is the perimeter or border of the system – elements, features, options, that will be included in the system.
Components of an Automated Information System
An IS is an arrangement of interdependent human and machine components that interact to support the operational, managerial, and decision-making information needs of the business’s end-users.
An IS is made up of:-
Hardware
Software
People
Data
procedures
An Automated Information System
Characteristics of an Information System
Data – are either (I) input via some data entry device, (II) already in the system and stored on a storage device, or (III) displayed or printed on an output medium.
Function (process, method) – is a transformation or action taken by the IS. Functions carry out and enforce business policies, rules, and procedures.
Behaviour – is the observable effects of a request.
Basic Characteristics of an IS
Data: input, stored, or output
Function: business activity performed
Behaviour: the observable effects of a request
Systems Development Process
(Overview)
(Overview)
SA & D takes a much broader perspective and focuses on:
Systems Planning – performing planning and initial feasibility activities to determine which IS projects take priority over others.
Systems Analysis – understanding and documenting the requirements of a specific problem domain. A problem domain refers to the business problem or function being planned, analysed, designed, and ultimately implemented as an automated IS.
Cont…
Systems design – designing an appropriate solution for the problem domain based on the documented requirements from SA.
Systems Implementation – constructing, testing and installing the information system and having the users use the IS.
Systems Evolution – maintaining and enhancing an IS so that it continues to meet the needs of the business.
What does a Systems Analyst Do?
A systems analyst studies the problems and needs of an organisation to determine how people, methods, and computer technology can best accomplish improvements for the business.
Look at how information is used, handled and manipulated in an organization.
Cont…
Identifying inefficiencies in the current system that the organization is using e.g delays, high operating costs,huge clerical effort.
Analyze the results of the investigation that will lead to designing the system.
Design and specification of a new system which overcomes the inefficiencies and meets organization objectives.
Oversees the process of testing during the testing of the system.
Qualifications of SA
Very wide and deep understanding of the concepts of IT.
Ongoing interest in updating one’s knowledge in IT.
Qualities of a SA
Working knowledge of IS Techniques and Technology
Computer Programming Knowledge
Problem-solving skills (creativity)
Interpersonal Relations skills (confidence, persistent, patience)
Interpersonal communication skills
Cont…
NB. These teams will be created and disbanded as projects are started and completed or cancelled.
The analyst may be viewed as a facilitator. The analyst acts as the interface among many different types of people and facilitates the development of computer applications through these people.
The analyst may well be the only individual who sees the big picture of the system.
Steering Committee
This committee is formulated in the organization to oversee the Systems Study and thereafter.
Steering Committee is usually composed of cross functional, senior managers within a business:
Personnel from IT department
Vice presidents / directors
Accounts department
Administration
Cont…
Data processing department
SA team (if it’s from outside)
Senior Information Systems Manager
The main role of this group is to conduct high-level reviews and evaluations of proposed IS development projects and make recommendations for prioritization and resources for the projects.
Cont…
Study, determine and maintain an IT policy for the organization.
Get views and requirements of the user dept to be represented as they try to look for solutions for the entire organization.
Initiating IT systems development projects.
Interviewing and appointment of IT personnel.
Selecting suppliers and negotiating supply contracts with them and include penalty clauses.
Cont…
Vendors are those businesses which support the IS development effort, such as consultants, hardware, software companies, training companies, telecommunication companies, documentation companies, and so on.
Where do Systems Projects Originate?
New or changed IS development projects come from problems, opportunities, and directives and are always subject to one or more constraints. Most maintenance of existing IS projects come from users discovering real problems with existing IS.
Problems – may either be current, suspected, or anticipated. Problems are undesirable situations that prevent the business from fully achieving its purpose, goals, and objectives.
Cont…
An Opportunity – is a chance to improve the business even in the absence of specific problems. This means that the business is hoping to create a system that will help it with increasing its revenue, profit, or services, or decreasing its costs.
A Directive – is a new requirement that is imposed by management, government, or some external influence. I.e. are mandates that come from either an internal or external source of the business.
Constraints are limitations and compromises that come with the soon to be developed IS.
Systems Development Life Cycle
The Systems development life cycle (SDLC) is the process by which an IS comes to life and maintains its usefulness to a business as it moves from inception to replacement.
Systems planning – planning for the new system.
Feasibility study (optional) – determines whether or not significant resources should be committed to the other phases of the life cycle.
Systems study and Analysis – requirements determination.
Cont…
Conceptual (logical)– define the inputs, files, processing, and outputs for the new system.
Physical design – outputs, inputs, files, methods, and procedures, internal controls, (these can be done by prototyping).
Construction, and testing, or purchase, testing, and integration.
Implementation – Conversion from current system to new or changed system; Training.
Evolution for enhancements and maintenance – continuous systems support.
The system is for the end-user. Get the end-user involved through out the systems development.
Establish phases and tasks to better manage systems development projects.
Systems development tasks aren't strictly sequential. They can overlap. Also, you may need to backtrack / revisit to correct mistakes.
Systems are capital investments. They should be economically justified as such.
Establish checkpoints to re-evaluate feasibility, and don’t be afraid to cancel infeasible projects despite sunk costs.
Documentation should be the natural, working by-product of systems development. Don’t post document phases or tasks.
Feasibility Analysis and Requirements Determination
Feasibility Types – Technical, Operational and Economic, and others
Requirements Determination Sub activities
Fact gathering techniques
How to Survey Feasibility of the project and study the current System
To understand the current system and its problems and to determine if solving the problems would be beneficial.
NB: The Survey phase is a preliminary investigation of the system, whereas the study phase is a much more detailed investigation.
Feasibility Study
Feasibility study:
Is the measure of how beneficial the development or enhancement of an IS would be to the business.
A preliminary investigation is done at this stage.
Define the problem – it provides a broad statement of user requirements in users terms, or what the users expect the system to do (project goals)
Cont…
This phase also sets project bounds, or scope of the system which defines what part of the system can be changed by the project and what parts are to remain unchanged. Document flow diagrams & a context diagram may help at this stage.
Identify the users of the system.
Specify the resources to be made available for the project (resource limits).
Cont…
Propose general Hardware/systems software options in broad terms (client-server configuration), which is necessary to size the project.
Perform a value assessment, such as the cost-benefit analysis, based on the project size.
Assess the project risks.
Recommend whether to proceed with the project or abandon the project
Cont…
project goals, project bounds and resource limits are some times called a project’s terms of reference and set by the management of the organization.
Feasibility Types
Operational feasibility – is the measure of how well a particular IS will work in a given environment. I.e. will the solution fulfill the end-users’ requirements? Will the organizational change result in an acceptable quality of working life for those affected by the system?
Technical feasibility – is the measure of the practicality of a specific technical IS solution and the availability of technical resources. I.e. Do we have the technology & skills needed to develop & operate the system?
Economic feasibility – is the measure of the cost-effectiveness of an IS solution. I.e. Will the system result in competitive advantage to the enterprise?
Legal – Will the proposed system conform to laws & regulations?
Ethical – Will the proposed system conform to the norms of ethics?
Other aspects of feasibility study:
What volumes of data will be handled, what numbers of users in various categories will be supported and with what levels of service, what file & database capacities the system will need to maintain, and other quantitative estimates of this type.
What interface will be provided for the users to interact with the system, based on the skills & computer proficiency of the intended users.
What control measures will be undertaken in the system.
Requirements Determination
It addresses the gathering and documenting of the true and real requirements for the IS being developed.
A Problem Domain – refers to the business problem, area, or function being investigated and analysed.
The purpose of the investigation and analysis is to determine the need to purchase, make, or revise an IS to enhance the business activity of the problem domain.
Requirements is the wants and /or needs of the user within a problem domain.
Frameworks for understanding and doing Requirements Determination
Requirements Determination Sub activities - Requirements determination is the general data-gathering activity done during analysis. It has 4 sub activities: -
Requirements anticipation – the SA hypothesizes that particular requirements are relevant based on his or her previous experience with other similar systems and knowledge about the problem domain.
Requirements Elicitation – the SA uses this activity to gather the essential requirements from the user employing a variety of techniques, such as interviews, questionnaires.
Cont…
Requirements Assurance – the SA uses this activity of requirements assurance to validate and verify the requirements with the user as being the real and essential requirements.
Requirements Specification – this is the activity that the SA uses to explicitly catalog and document the requirements either during or after the elicitation and assurance activities.
Cont…
The PIECES Framework - Focuses on the actual work of doing requirements determination. The model is used to classify identified requirements into one of six subject areas:- Performance, Information, Economy, Control, Efficiency, and Services.
Performance questions address how the system needs to perform for the user. Issues of throughput and response time are considered.
The Information category provides the basis for the information or data model that the system needs to maintain. Issues dealing with input data, output data, and stored data are considered.
Cont…
Economy addresses project development and operational cost information along with any objectives that may relate to economy or savings associated with the system.
The Control category is closely associated with system security issues as well as the editing required on the incoming data. Any issues related to controlling the use of the system, its outputs and inputs, or required controls over the data can be included in this category.
Efficiency is a measure of method correctness. I.e. are things being done right?
Services are functional requirements of the system.
Cont…
Object-oriented Requirements Determination Modelling Activities – emphasizes objects, patterns, responsibilities, and scenarios.
An object is a person, place, or thing, such as student, faculty, sales clerk, city hall, ATM machine.
A pattern is a template of objects with stereotypical responsibilities and interactions; the template may be applied again and again, by analogy. Pattern instances are building blocks used to assemble effective object models.
Responsibility is associated with objects and has three aspects to it: “What I know,” “who I know,” and “what I do.”
What the object knows about itself – the things that an object knows about itself are called attributes. An attribute is a characteristic associated with a person, place, or thing object. Each characteristic has a state or value.
Who the object knows – a problem domain has many objects within it. Who the objects knows identifies relationships between objects.
What the object does – this translates into a list of services for each object. A service is some functionality that an object is responsible for performing.
A scenario is a time-ordered sequence of object interactions to fulfill a specific responsibility. A scenario would be developed for each of the preceding services.
Cont…
Coad’s object-oriented requirements determination modelling approach would involve the following four major activities:-
Identify purpose and features of the IS.
Identify objects and patterns.
Establish object responsibilities: “What I know,” “who I know,” and “what I do.”
Work out the system’s dynamics using scenarios.
Methods Used to gather an IS Requirements
Information Gathering Techniques
Asking the users
Interviews - Is a planned meeting during which you obtain information from users of the existing system.
Advantages of interviews
An opportunity to gather information from respondents who are knowledgeable about the system under study.
Cont…
Best source of qualitative information I.e. opinions of people, policies, and subjective description of activities and problems.
Useful for respondents who do not communicate properly in writing or are lazy to complete questionnaires.
Allow SA to discover areas of misunderstanding unrealistic expectations and indications of resistance to the proposed system.
Cont…
Disadvantages
Subjective and sometimes irrelevant.
Communication problems
Misunderstandings can rise from different user values, or technical jargons by the SA.
Guidelines to interviewing
The interviewer should acquaint him/herself with the work of the person he/she is going to interview.
Cont…
Prepare before hand.
Make an appointment, and the interview takes place away from the interviewee’s place of work to avoid interruptions.
The interviewer should do little talking, let the interviewee do more talking, and make sure the discussion stays on truck.
Be able to separate his/her opinion from facts and fictions from facts.
Interview one person at a time.
Cont…
Avoid the temptation to try and cover too much ground.
End with a brief statement of what has been discussed. I.e. give a summary to the interviewee to cross-check with what been discussed, and if there are any misconceptions, corrections are made.
Cont…
Questionnaires – is a document containing a number of standard questions that you ask of a large number of people.
Advantages
Can be filled by a large number of respondents.
Can get reliable information.
Allow collection of data and can be filled in at leisure.
Cont…
Use of standardized formats yield more and reliable data.
It also ensures anonymity of respondents which can lead to more honest responses.
Disadvantages
Misinterpretation of the question.
Does not lead to further/deep probing.
They don’t allow analysts the opportunity of observing and sensing reactions.
Guidelines to Questionnaire design
Should begin with a preamble
Bear in mind the level of intellect and the level of interests of the respondents
Keep questions short, unambiguous and unbiased, and where possible have multi-answers.
If possible avoid too much branching.
If the survey is extensive, you may consider use of automated means of reading responses.
Pretest the questionnaire before using it for the purpose of checking whether all the questions will be easily understood.
Group Decision-making process/Formal Sessions
Workshops and Brainstorming sessions are increasingly being used to draw out new ideas for systems.
Get people who are familiar with the issues together to spontaneously explore ways of improving a system.
Delphi technique, group members may be scattered around the world. A questionnaire may be circulated.
Cont…
No criticism
“Anything goes”
The more the better
Build on the ideas of others
Cont…
Deriving from an existing system
The system that will be replaced by the proposed system
A system similar to the proposed one that has been installed elsewhere & is accessible to the analyst
A proprietary package, whose functionality may be analyzed.
Cont…
Data analysis: The requirements for the proposed system are derived from the data contained in inputs (orders, invoices, time cards etc.) or data contained in the outputs (reports, worksheets) of the existing system
Sampling of existing Documentation – when you are studying an existing system, you can get a good idea by studying existing: documentation,forms, and files
Cont…
First document that analyst should seek out is the organizational chart
Be sure that they are relevant and up-to-date
Document analysis usually accompanies the “asking” methods, as documents are difficult to be interpreted independently.
Observational Studies
Systems Analyst participates in or watches a person perform activities to learn about the system.
often used when validity of data collected through other methods is in question or when the complexity of certain aspects of the system prevents a clear explanation by the end users.
People usually feel uncomfortable when being watched.
Cont…
Advantages of Observations
Permits correction of any misconceptions or erroneous impressions made before.
Permits verification of statements made in interviews as well as determine if procedures operate as specified in the system documentation.
You become better acquainted with the operating personnel who will be implementing the new or changed system.
Measuring – It is important in systems investigation, analysis and design in terms of:-
Magnitude of the exercises
Processes
Quantity of work
Time taken to accomplish work (time frame works)
Rates of doing work
Intervals
These help to determine the systems requirements, e.g s/w, h/w e.t.c…
Deriving the requirements from the analysis of the business area
Using Business Systems Planning (BSP)
Using Business Systems Planning (BSP)
Critical Success Factors methodology
“Those few critical areas where things must go right for the business to flourish”
“Those few critical areas where things must go right for the business to flourish”
Establish informational needs of an individual manager by decision analysis
Identify the key decisions that a manager makes
Define the process by which the manager makes these decisions
Define the information needed for the decision process
Establish what components of this information will be delivered by the information system and what data will be needed to do so.
Cont…
Prototyping
A method used to test or illustrate an idea and build a system in an explorative way.
Used to discover user requirements
Allows analyst to quickly create mock forms and tables to simulate the implemented system.
Valuable for the design of the end user interface of an IS. Users’ needs and behavior are not entirely predictable and are strongly dependent on the context of the situation. So it enables users to react immediately to the parts of the system they will be dealing with.
It is more likely to produce a system that will fulfill user requirements, especially when it is used for decision-support applications.
Cont…
It promises to eliminate excess development costs and design flows that occur when requirements are not fully captured the first time round.
User satisfaction and morale are usually heightened because users can be presented with an actual working system, preliminary though it may be in a very short period of time.
Cont…
Disadvantages
Prototyped systems still need to be fully documented and tested, but often these steps are shortened.
The final step to convert the prototype into a polished production system may not be carried out. I.e. if it works reasonably, management does not / may not see the need for reprogramming and redesigning.
Systems Analysis – Tools and techniques:
Users Requirement Document
Decision Tables, Decision Trees, Structured English
Process Modelling with Data flow diagrams (DFDs).
Data Modeling with Entity Relationship Diagrams (ERDs).
Requirements Analysis
This process is usually characterized by the following activities:
What outputs the system will produce, what inputs will be needed, what processing steps will be necessary to transform inputs into outputs, and what data stores (files or databases) will have to be maintained by the system.
Types of Requirements
User Requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
System Requirements
A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor.
User Requirement Document
User Requirement Document (URD) – What the system should do (user requirement analysis).
Systems Analysts have to work out between themselves on what the system should do. They are guided by the URD. The URD has 4 categories of information:
Functional Requirements – these describe the desired functionality of the new system I.e. what is expected of the system in behavior terms e.g outputs and inputs of the system.
The user shall be able to search either all of the
The system shall provide appropriate viewers for the user to read documents in the document store.
The system shall be designed in a way that makes it easy to update and easy to use.
Non-Functional Requirements – these have the effect of limiting the choice so that if there many possible designs can be eliminated and don’t have to be assessed. They’re sometimes referred to as constraints. Usually concerned with the h/w, s/w, time and money constraints. Examples of NFR:
The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
The product shall use the company colors.
Only direct managers can see the personnel records of their staff.
Design Objectives – these are attributes of s/w that would enable comparison. Once the designer appreciates the relative importance that the user attaches to a certain property then that would be the most outstanding design objective e.g. should be user friendly, maintainable, easy to develop.
Design Decisions – these are premature statements usually requested by experienced users e.g. how the behavior is to be achieved rather than what behavior is required.
Such statements should be withdrawn or interpreted as non-functional requirements.
URD Diagram
Example of A Decision Tree for a Discount Authorization process
Example - Discount Authorization Process
Cont…
Decision Tables – It is a tabular description of a selection structure. I.e. It is a graphic method for describing the logic of decisions. It provides a means of documenting procedures in which several complex decisions have to be made.
Decision Table diagram
Cont… Decision Tables
Condition Statement – identify relevant items
Condition Entry – identify which value if any apply a particular condition.
Action Statement – will list all the steps that can be taken when a certain condition occurs.
Action Entry – identifies what specific actions in the set to take when selected conditions or combinations of conditions are taken.
Example: Insurance Application Process
Instructions to an insurance clerk reads as follows:
Policy type 22 may be issued if the applicant has been issued with policy type 19 and is a married male or has been issued with policy type 19 and is married and under 25years. Alternatively if the applicant has not been issued with policy type 19 and is married female, policy 22 may be issued. Then a policy may also be issued to a male under 25 years, or married person who is 25 years or over. All other applicants are refused.
Insurance Application Process
Cont…
Advantages of Decision Tables
Is concise, unambiguous, clearly conveying the logic involved, hence less danger of omitting a logical possibility.
Enhanced communication with action separated from conditions.
Easier to draw and they’re easily understood.
Produces an automatic compact program documentation.
Cont…
Its format is highly standardized.
Can be checked mathematically for completeness and that all test combinations have been considered.
Disadvantage – however, they don’t show the sequence of decisions.
Structured English - It is based on structured logic, or instructions organized into nested and grouped procedures and simple English statements such as add, multiply, move e.t.c.. I.e. it describes logical processes precisely and concisely. I.e. it uses narrative statements to describe a procedure.
Developing Structures which express problem solutions:
Sequence Structures – Is a single step or action included in a process. I.e. the completion of one process step in sequence after another process step. It doesn’t depend on the existence of any conditions, so when encountered, it is always taken.
Cont…
Decision Structures – Occurs when two or more actions can be taken. I.e. the completion of one or two process steps based on the results of a test or condition. One must assess the condition and then make a decision to take the stated actions.
Iteration Structures – the completion of a process step repeated until the results of a condition terminates this repetition.
Discussion Question
When should a Systems Analyst choose a particular process description tool / technique to use? (Guidelines for choosing a technique to use).
Structured Analysis
It deals more with the logic of the system – requires the analyst to define what the system should do. I.e. breaking down the system into manageable subsystems – method for defining systems inputs, processes, and outputs, and for partitioning systems into subsystems or modules that show a logical graphic model of information flow.
Objective of Structured Analysis - Is to document all the end user requirements for the proposed IS and present these requirements in the systems requirement document.
Structured Analysis accomplishes the following:-
Views the system from the top to down.
Specifies the interfaces that exist between modules.
Rigorously specifies the processes or transformations that occur within each module.
Data Dictionary – description of all the data used in the system.
Cont…
Graphic Symbols – icons and conventions for identifying and describing the components of a system and relationship among these components.
Procedure and Process description – formal statements using techniques and languages that enable systems analysts to describe important activities that make up a system.
Cont…
Data Flow Diagrams – show how data moves and changes through an IS in a graphical top-down fashion. I.e. a graphic representation of a system’s components processes and the interfaces between them.
Process Modelling with Data flow diagrams (DFDs)
DFDs are useful for modelling the scope of a systems project in terms of its interfaces with other systems, the business as a whole, and the outside world.
DFDs show how data flow to, from and within an IS and the processes that transform data. They also show where the data are stored.
Cont…
DFDs are constructed using 4 symbols:
Data flows ( ) - these show the movement of data between processes, external entities, and data stores in a DFD.
Processes ( ) – they portray the transformation of input data flows to output data flows in DFDs.
Cont…
Data Store ( ) – are either manual or automated inventories of data. E.g. computer files or databases, file cabinets, card files, microfiche e.t.c…
External Entity ( ) – are originators or receivers of information outside the scope of the IS portrayed in the data flowing.
Cont…
General rules for drawing DFDs
Any data flow leaving a process must be based on data that is input to the process.
All data flows are named and the name reflects the data flowing between the processes, sources, and data stores.
All the data needed to perform the process should be input to that process.
The process should be independent of any other in the system – each process has its own input and output.
Context diagram - It is a simple DFD that depicts the system being studied as it relates to other systems, the business, and the outside world – the interfaces flowing to or from external entities.
DFDs can be drawn in various levels of details using a technique known as levelling, ranging from depicting an entire system’s “big picture” to showing the detailed processing of a single transaction. The entire collection of DFDs is called a levelled set.
Document Flow Diagram
A diagramming technique which is used to identify physical movement of documents.
It shows where the document comes from, where it goes to , and what it is called.
The source and destination of the document are usually shown using an elliptical shape.
For each document or communication that occurs in the system, identify the source and the target. This will help in developing a context diagram during analysis.
Document Flow Diagram of a Purchasing System
Data Modelling using Entity Relationship Diagrams
Data Modelling using Entity Relationship Diagrams
A data Entity is anything, real, or abstract about which we want to store data. Most entities correspond to persons, objects, events or locations in the business environment.
A data Relationship is a natural association between entities. All relationships are further described by words or symbols that indicate the number of occurrences of one entity that can exist for a single occurrence of the related entity.
In the definition phase, we look at requirements independently. I this phase, data modeling is performed. Entities, data elements and relationships are identified.
Data models complement process models.
In the selection phase, the following are addressed:
The new files and databases to be designed are identified.
How much data should be automated?
Should it be central or distributed data storage?
How relationships between data entities be stored?
Systems Design
Architectural design process
Output design, input design, User interface design, file & database design, program specification design
Prototyping
Systems Design
Systems Design – details how a system will meet the information requirements as determined by systems analysis.
Note that the primary input to design is the requirements specification document, which is the output from analysis. This document is critical to the success of the system because it represents the users’ requirements for the system.
Cont…
Much of the contents of this document get transformed into design equivalents as the systems analysts begin to customize the proposed IS for the specific h/w and s/w platforms to be used for its creation and ultimate operation in some production environment within an organization.
These specifications should be detailed enough to become inputs to the programming stage that follows the design. The design process is usually broken down into two parts.
Cont…
Logical design – produces the general specification of the resources that will make up the system - lays out the components of the IS and their relationship to each other as they would appear to users.
Physical design – produces a complete, detailed specification of the named program components and of the databases to be maintained by the system - the process of translating the abstract logical model into the specific technical design for the new system.
Cont…
This activity addresses all of the environment, platform, and human-computer interface specifics for the proposed information system. Issues to be discussed and decided here include all aspects of the five components of an information system such as: hardware, software, data, people, procedures.
Objectives of Systems Design
Specify logical design elements – detailed design specifications that describe the features of an IS: I/P,O/P, files, databases, and procedures.
Support business activities – results of using the system help business performance. Design fits the way the firm conducts its business.
Cont…
Meet user requirements – in terms of:- performing appropriate procedures correctly; presenting proper form of information; providing accurate results; using appropriate methods of interaction; providing overall reliability.
Easy to use – favorable human engineering; ergonomic design that is physically comfortable and contributes to user effectiveness and efficiency.
Cont…
Provide software specifications – specific components and functions with adequate detail to construct application software.
Confirm to design standards – design and specification of the design in accordance with prescribed rules and practices of the organization.
Architectural Design
The design process of identifying subsystems of a large system and establishing a frame work for sub-system control and communication.
It involves identifying major system components and their communications.
A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.
A module is a system component that provides services to other components but would not normally be considered as a separate system
Architectural design process
System structuring
The system is decomposed into several principal sub-systems and communications between these sub-systems are identified
Control modelling
A model of the control relationships between the different parts of the system is established
Modular decomposition
The identified sub-systems are decomposed into modules
What features must be designed – Logical Design
Design specifications describe the features of a system. These are the elements of the system and their appearance to the users. These include:
Data Flows – the movement of data into, around, and out of the system are specified.
Data Stores – temporary or permanent collections of data are specified
Cont…
Processes – activities to accept, manipulate, and deliver data and information, may be manual or computer-based are specified.
Procedures – methods and routines for using the IS to achieve the intended results are specified.
Roles – the responsibilities of all persons involved with the new system, including end-users, computer operators, and support personnel are specified.
Cont…
Controls – standards and guidelines for determining whether activities are occurring in the anticipated or accepted manner I.e. under control. It also specifies actions to take when problems or unexpected circumstances are detected. May include the reporting of exceptions or procedures for correcting problems.
Physical design
When physical design is completed, the following aspects of the system will have to be specified:
System outputs – report layouts, document designs, screen designs
System inputs – data inputs & their validation procedures
User-system interface – exact protocols of user-system interaction (menu trees, icons for graphic interfaces etc.)
Platforms – H/W & S/W platform (s)
Acquisition method – the way each component of the application will be acquired
Modular design of the programs that will be developed for the application, interfaces between the modules, and the specification of the logic of the individual modules. The algorithms to be implemented in each module will be selected.
Detailed test plan – the plan for various levels of testing to be conducted during the later stages of development & a test suite containing the sets of tests for these levels.
Database – logical & physical designs. Needed capacities of files & databases have been estimated.
Controls – application-specific controls, as well as the necessary general controls.
Cont…
Documentation – a full set of documentation to be delivered with the system is specified. The documentation will include the user manual, systems & operation documentation, maintenance documentation.The requirement specification & the system design documentation will also be included in the documentation package.
Conversion plan – the plan for converting the present way of doing things to the new system
Techniques & Tools used in design
Structured design - The principal product of logical design are structure charts of the programs that need to be coded & tested. They are of 2 kinds:-
Modular structure
Hierarchical design
Cont…
After the logical design stage, the processing steps to be carried out by individual modules are specified in physical design.
Prototyping – 4GLs, AG
Joint application development (JAD) – participative development
Rapid application development (RAD)
Object oriented design (OOD)
USER INTERFACE DESIGN
User interacts with the computer system through a combination of means – User Interface
User Interface is the yardstick by which the system is judged by the user
Difficult to use Interface will cause errors, the system may be discarded, meaning of information may be misunderstood, may corrupt data, may cause system failure
Text based interfaces were used in the early days
Replaced by Graphical User Interfaces (GUI)
Cont…
Windows – Several windows on the screen enable the user to work with several programs, either simultaneously (multitasking) or on one
Icons – little pictures which may represent files or processes
Menus – Commands selected from a menu rather than typed in a command language
Pointing – Pointing devices such as a mouse to point at a selection from a menu or point at an icon & then click to issue the command
Cont…
Graphics – Graphical elements mixed with text in the same display
User Interface design must take into consideration the capabilities of the user
Prototyping may be helpful
Short-term memory of humans is limited, do not overload with information
Consistency in the Interface helps to reduce errors, comparable operations should be activated in the same manner
Cont…
Use terms & concepts familiar to the user
Recoverability – Confirmation of destructive actions, Undo facility
Help facilities – Structured help facility at different levels, Context sensitive help
Information from the user to be given to the Computer system
Information from the Computer system to be presented to the user
Direct manipulation ( as in word processing, screen editors, form-based interfaces)
Desktop metaphor
System entities are represented as icons
In addition the use of a control panel with buttons, switches, menus, indicators, displays, sliders
Cont…
Menu Systems
Point with a mouse
May use cursor moving keys
On touch-sensitive screens use the finger or pen
Do not need to remember commands
Typing effort is minimal
User errors of a certain type can be avoided
Most frequent operations at the top of a menu
Most destructive operations at the bottom
Command-line Interfaces
Allow faster interaction
Command language has to be learnt
Command language programs can be written
Cause more errors
Interface cannot use pointing devices, interaction is through the keyboard only
Out put design
Characteristics of good output – there are several characteristics that make information a candidate to be considered both highly quality and usable:
Accessibility – This characteristic refers to how easy it is to use the information when a person gets it.
Timeliness – This characteristic refers to the amount of elapsed time it takes to obtain specific information that is needed
Cont…
Relevancy – this characteristic refers to whether the information as presented is free from trivial or superfluous details or lacking in sufficient details.
Accuracy – This characteristic addresses the issue of error-free information.
Usability – This characteristic refers primarily to the presentation style of the information, I.e. its format. E.g text, numbers, graphics, graphs e.t.c…
Cont…
Output types
Internal, External, and Turnarounds Outputs – Internal outputs are intended to be used by people or other information systems within a business.
External outputs are intended to be used by people or other information systems outside the business.
Turnaround outputs this type of output is generally external and people oriented and has the dual purpose of serving as output to the user and input to the information system from the user.
Cont…
Static and Dynamic outputs
Static outputs are those that can be predetermined and planned for.
Dynamic Outputs are those that cannot be easily predetermined or planned for during information systems development.
Output devices and media
Plotters are most often used to draw maps, architectural drawings, and blueprints, graphs, and pictures.
Cont…
Computer output on Microfilm or microfiche are devices that, as their name implies, produce microfilm or microfiche output.
Interface Evaluation
Usability of the Interface
Meets the user requirements
Learnability - How long it takes a new user to become productive with the system?
Speed of Operation – How well does the system response match the user’s work practice?
Robustness – How tolerant is the system of user error?
Recoverability – How good is the system at recovering from user errors?
Adaptability – How close is the system tied to a single model of work?
Cont…
Questionnaires, Observation of users at work, Inclusion of SW in the code to collect information about most-used facilities and most common errors.
Specific questions must be asked from users for evaluation (e.g. Error messages)
Files and Database Designs
Files for data storage
Files are generally used to store sequences or lists of data in a format that has been optimized for some particular type(s) of transaction, and require routines specifically written for those formats and transactions.
Files are generally used to store sequences or lists of data in a format that has been optimized for some particular type(s) of transaction, and require routines specifically written for those formats and transactions.
Generally these are organized sequentially, adding new data records to the end of the file. They are often arranged in a linked-list format for ease of manipulation.
File types by their area of application
Master files: are files used to record key business information which is maintained over a long period of time. Typical examples include order information, customer and account information, etc.
Lookup files: are files containing static values, generally used for validation. Common examples are postal codes, province, state, and city names, etc.
Cont…
Transaction files: are files which hold information used to update the master files. For instance, we might have a transaction file which records all the orders placed today and is used to periodically update the master file. Thus the "current" state of the system is maintained in memory, but in the event of a discrepancy or system failure we can check the master file against the day's transactions to determine where the failure occurred and how to correct it.
Cont…
Audit files: audit files are used to record key information immediately before and after a transaction is applied. For instance, we could take a snapshot of an account immediately before applying a withdrawal transaction, and another immediately afterwards. Again, in the event of an error or system failure during the transaction the combination of master file, transaction file, and audit file allow us to pinpoint exactly what went wrong and how to correct it.
Cont…
History files: many such systems collect vast amounts of data over time, and much of that data is rarely required. As such, it is common to create an archive of old data - data moved into a more compact and/or cheaper storage mechanism so that the overall system is more efficient but the data is still recoverable if necessary.
File Access and Organisation
File Access: refers to the method of reading or writing records within a file.
File Organisation: refers to the method of storing records within a file.
Two methods for accessing records in a file: sequentially and directly
Four ways of storing data in files: serial, sequential,direct, and indexed.
Methods for accessing records in a file
Sequential access: is access by physical record location or position within a file (i.e. Starting at record one and sequentially reading or writing every record to the end of the file).
Direct access: is access by physical address (i.e. ability to go directly to certain records within files without having to sequentially scan from the first record in the file).
Methods of File Organisation
Sequential file organisation: a method of storing data records in which the records must be retrieved in the same physical sequence in which they are stored (e.g. batch processing applications such as a payroll).
Direct/ Random file organisation: a method of storing data records in a file so that they can be accessed in any sequence without regard to their actual physical order on the storage media.
Cont…
Serial file organisation: is the storing of records in a file in chronological order (e.g. Recording of a bank’s ATM transactions as they occur).
Indexed file organisation: uses and maintains a sorted index in key order, which stores the record location of the actual data file record as part of the index.
Cont…
Databases for data storage
Databases are used to store logical data groupings and their relationships, and require a database management system (DBMS) to maintain and access the data. Databases come in a vast range of sizes and complexity, from small scale systems such as Microsoft Access to full-fledged business or enterprise DBMSs such as Oracle.
Databases are used to store logical data groupings and their relationships, and require a database management system (DBMS) to maintain and access the data. Databases come in a vast range of sizes and complexity, from small scale systems such as Microsoft Access to full-fledged business or enterprise DBMSs such as Oracle.
General categories of database systems
Legacy databases: are databases using older, outdated technologies. They are frequently encountered in large organizations where the cost of replacing the database is prohibitive.
Relational databases: are the most common/popular current form of database, primarily because they are much easier systems to perform development and maintenance on. These databases are composed of a set of tables, composed of a fixed number of rows (records) and columns (fields within each record).
Cont…
Each table has a primary key (uniquely identifying each record in the table) and which may have one or more foreign keys. These foreign keys define the relationship to another table, and would be the primary key of the other table.
Some of the most common RDBMSs include Access, Oracle, DB2, and Microsoft SQL Server.
Cont…
Object databases: are databases which try to encapsulate logical data entities and their associated processes as separate objects. This makes it easier to alter portions of the database, since changes within one object do not impact other objects. Object-oriented data base management systems (OODBMSs) are primarily used in supporting multimedia applications, but they are also becoming more common in large scale electronic commerce systems.
Software Construction and Testing
General software design principles
Construction strategies
Testing principles
Testing strategies
The Generic software testing methodology
General software design principles
The software must conform to the requirements specification document created during the analysis portion of the project and any modifications added later during design – with time the original specification requirement document becomes obsolete, hence changes may not be reflected.
The software must be reliable over time while processing a potentially limitless combination and types of data, as well as user keystrokes and pointing device (mouse clicks).
Cont…
The software must be maintainable and evolutionary over time – upgradeable to accommodate changes.
The software must be easy to use (user friendly).
The software should be easy to test and implement using the test plans.
The software should use computer resources efficiently – minimize computer resources e.g. memory, processing power.
The software should work correctly – should avoid errors.
Software Construction Strategies
Top-Down software construction – follows the functional decomposition approach to problem solving. It starts with the design overview or high-level view (control or management oriented e.g. menus & calling modules) of the system and then creation of the program code for it. Next the details of the system are written for the program code, layer by layer, until the bottommost modules are programmed (operational or worker oriented e.g. modules which calculate results, update databases, print lines on a report).
Cont…
Bottom-up software construction – starts with writing the program code for the lowest-level details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system. Next is the construction of the code for the modules or modules that calls these bottommost modules.
Cont…
Middle-out software construction – starts somewhere in the “middle” of the system that seems convenient, and proceeds both upward to higher levels and downward to the lower levels as appropriate (e.g. coding a low-level module that opens a file, or calculates sales tax (bottommost modules)).
The Hybrid combination of top-down, bottom-up, and middle-out software construction may be suitable for certain environments or projects.
Software Testing Principles
It should conform to at least three principles:
First principle is that Software testing begins with plans for the tests and ends with the user accepting the tested software. Software test plans should be developed at the same time the requirements specification document is being developed and can be refined and updated during design as well. The plans for the user acceptance test should conform to the user requirements as documented in the requirements specification document.
Cont…
By doing so, the development loop is completed, and the software is certified to be in compliance with the requirements specification document. User acceptance test plans include more than just the software; they include the other four IS components-hardware, procedures, people, and data.
The second software testing principle is that testing’s intent is to cause and discover errors – testing should be done with as little pride of ownership as possible.
Cont…
The third software testing principle is that rules of reasonableness should prevail – testing should follow commonly accepted testing techniques designed to provide a certain threshold of statistical confidence in the tests (e.g. rather than testing every record in a large database for a certain sequential processing situation, one commonly accepted testing technique is to test the first record, a few records in the middle of the database, and the last record I.e. test the huge actual database).
Software testing strategies
Top-down testing – follows the functional decomposition approach to problem solving. It starts at an overview or high-level view of the system to be tested, then works its way down into details of the system, layer by layer until reaching the bottommost programmed modules.
Bottom-up – testing starts with details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system.
Cont…
Middle-out testing – starts somewhere in the “middle” of the system that seems convenient, and tests both upward to higher levels and downward to lower levels as appropriate.
Hybrid is a combination of the three above.
Regardless of which testing strategy is chosen, software testers view portions of the system, subsystem, programs and modules as either a white box or a black box as they test.
White box is the portion of the system that we are testing from an inside perspective. I.e. there is the ability to actually look at the code statements within the white box portion being tested and make changes to them should they not work correctly.
Black box is the portion of the system that we are testing from an outside perspective. I.e. the tester doesn’t have the ability to look at the code statements and change them. (Usually done when programmers need to integrate that part of the system with the part of the system they are creating and testing). Usually done on software wrote by someone else.
Cont…
Alpha testing is testing done in-house by testers such as programmers, software engineers and internal users. I.e. a first cut at the acceptance tests is done in-house by in-house staff.
Beta testing usually involves a select group of customers to perform tests on the software as they would use it in their normal environment. In exchange, the customers get an advance copy of the soon to be released software, which usually has new features in it.
A Generic Software Testing Methodology
A Generic Software Testing Methodology
The above generic testing methodology can be utilized regardless of whether the resulting software is to be used in house or is to be available for public sale at computer stores. Note the feedback or fall back arrows in the diagram. Whenever testing discovers errors at any level of the methodology, the programming staff will need to make coding changes followed by a trip back through the layers to ensure defect-free code in all test levels.
As testing takes place, keep in mind that code changes made by programmers in one module or section of a program may fix the identified bug but may cause an error in some other seemingly unrelated section of the program when it is tested again.
Large systems are built of sub-systems which are built out of modules which are composed of procedures & functions.
The testing process should be carried out in stages:
Unit/ Module testing – individual components are tested. I.e. Individual program modules are tested by their developers.
Cont…
Integration Testing – is the combining of several units or modules for the purpose of testing them as a whole.
As software is being constructed and simultaneously being tested for integration with other software modules by the programmer, a technique known as stub testing is often used. Stub testing is a test performed on individual modules as they are being integrated in a top-down, bottom-up, or middle-out manner.
Function testing – is the combining of one or more integration tested groups of modules that collectively perform a user identified function, as documented in the requirements specification document.
System testing – combines all of the user-defined functions together to form the subsystem or system.
Acceptance testing – is similar to system testing. However the user is the one who usually does the testing. These tests are most often conducted with well-defined test data, as well as the actual, real data.
The diagram below represents a framework for the methodology and how it interrelates with the other activities and deliverables of IS development.
System Development and Implementation
Individual system components are built and tested
User interfaces are developed and tried by users
Database is initialized with data
Users are provided with a working system (programs and database)
System documentation describing the programs is also completed.
All users are trained and can use the new system.
Systems Implementation; Evaluation & Review
Installation – conversion strategies; Activate; Institutionalization
Implementation Critical success factors
Evaluation and review
Implementation - is the conversion of data to the new system’s files, final training of the end users, and transition from the old system to the new system.
Marks the end of development for now, and begins the user’s realization of the new or changed information system.
Implementation is a critical time for users because the user must switch from the old to the new system, and the user must take responsibility for the successful utilization of the new system.
Cont…
The IS development team must anticipate, even expect, problems during implementation. Hopefully, the problems can be turned into opportunities.
Implementing a system consists of 3 phases : Install, Activate, Institutionalization.
Install – Is putting the new IS in place. I.e. physically install all of the five components:– h/w, s/w, people, procedures, data, of an IS. People are trained or prepared as part of the install phase.
Install Phase
A very significant part of the install phase has to do with conversion. Conversion is the switching from one thing to another. I.e a new IS is replacing an obsolete manual or automated IS. NB. Conversion affects each of the components of an IS.
There are three Conversion strategies of :-
Conversion
Cutover/Abrupt/Direct Conversion – is one in which the user uses the old system up to a specific point in time after which the user starts using the new system.
Advantages -
No duplication of effort for users.
No transition costs with the old system.
Learning advantage for groups converted later, if Cutover is done by groups.The costs of running parallel systems.
Cont…
Disadvantages of Cutover Conversion -
High risk I.e. It may disrupt operations if it fails.
Cannot compare results.
Sense of user insecurity I.e no period of adjustment could lead to resistance to change.
Cont…
Parallel Conversion – is one that allows the user to continue use the old system and the new system simultaneously for a period of time, eventually discarding the old system.
Advantages –
Low risk I.e. it guarantees continuing incase the new system fails.
Sense of user security
Ability to compare results with old system.
Cont…
Disadvantages of Parallel Conversion –
Duplication of effort for users
Transition costs I.e. Expensive
Additional processing strain on the computer.
Cont…
Pilot Conversion – is one in which the new system is implemented in one part of the organization such as a single department, and eventually extended to other departments.
Advantages –
Incase of failure, the rest of the organization is not affected.
Cont…
Based on feed-back, changes are made and the system is installed in the rest of the organization by one of the other methods.
It provides experience and live tests for implementation.
Gives an opportunity to the implementers to display the advantages of the new system.
Cont…
Disadvantages of Pilot –
May give the impression that the new system is un-reliable and not error-free, depending on the effectiveness of the implementers.
May give the impression that the old system is un-reliable and not error-free because staff may loose confidence in the old system.
Cont…
What do Software Engineers base their conversion strategy decision on?
The design of the information system.
User needs and preferences.
Risk factors.
Activate Phase
The second phase of Implementation, the Activate phase, deals with getting the user to use the new or changed IS.
Once the IS has been installed and the conversion performed, the implementation moves naturally into the activate phase as the predetermined users begin exercising and using the new system.
Cont…
During this critical phase the development team may continue training the users on an as-needed basis.
The team should also anticipate and expect problems and be prepared to correct them.
The team should also monitor the user’s usage of the IS, taking note of what the users like and dislike, patterns of user usage, shortcut opportunities to improve the IS effectiveness, e.t.c.
Cont…
In short, the development team needs to pay serious attention to the IS and its use by the users during this phase and be prepared to maintain, fix, and enhance it as the need and opportunity to do so become available.
Maintenance and Review – changes in h/w, s/w, documentation or procedures to a production system to correct errors, meet new requirements, or improve processing efficiency.
Cont…
Evaluation – this is to determine whether the IS operates as expected, and if the costs and benefits are as anticipated. I.e. identify the strengths and weaknesses of the IS.
Why Maintenance is important?
Necessary to eliminate errors in the system during its working life (corrective maintenance)
Enhancing & modifying the system to respond to changing user environment & organizational needs, improving system efficiency, & enhancing documentation (perfective maintenance)
Cont…
Changing the application to adapt it to a new H/W or S/W environment (adaptive maintenance)
Information system planners must always plan for resource availability to carry out these maintenance functions.
Institutionalization phase – means that the new or changed IS becomes the new status quo within the business.
Cont…
Status quo doesn't guarantee 100% use by the users, but it does imply that the new IS is now the standard for the business and that a certain percent of user critical mass has adopted and is using the new IS.
What are some of the reasons that lead to resistance of a new Information System by the users? Discuss in class.
Implementation Critical Success Factors
From an Organizational change perspective, successful IS implementation depends on the following critical success factors:
User Commitment – the user must be the champion or advocate for the new IS. I.e. the user should take ownership and responsibility for the new system.
Organizational trust – management and staff within the business, both IS types and user types, must have a high degree of trust in one another.
Open communication between IS management and staff and user management and staff – communication problems and breakdowns can cause significant harm to an IS development project and the IS implementation.
Financial commitment from user management – lack of or limited funding for the new system can cause significant problems during the development process and during the system's implementation.
Common view of the IS development and implementation strategy between management and staff.
Project Management
The project management causes of failed projects
The basic functions of the project manager
Project management tools and techniques
What is Project Management
The purpose of this module is to introduce you to project management.
Project Management is applied during Systems Analysis, Systems Design and Systems Implementation. Information Systems development is almost always done under the auspices of a project.
Definition of Project Management
Definition: Information Systems Project Management is a process of directing the development of an acceptable Information Systems at a minimum cost within a specified time frame.
NB: The acceptability, deadline and budget criteria must all be for a project to be considered completely successful. The role of Project Management is to recognize such factors to eliminate or minimize their negative effects.
Sources of Systems Development Projects
Systems Development Projects come from one of three sources: -
A directive or mandate from some person, such as a president, vice president, or senior Manager, or an organization such as a labor Union or Uganda Revenue Authority.
An opportunity to exploit. The opportunity usually results in increased revenues and/ or profits reduced costs, or increased or improved services.
A problem to solve. Something usually isn’t working correctly and needs fixing.
Systems Development Failures
Use of undisciplined development methodologies or approaches.
Inadequate or not understood or appreciated Systems Development tools.
Project Scope was not clearly defined in the beginning.
Use of no or poor estimating techniques.
Schedule delays.
Cont…
Beliefs in the mythical person- month syndrome. E.g. a Manager with this mindset thinks that if two developers can do or finish up a project in six weeks, then simply adding a third developer to the project will allow it to be completed in 4 weeks. The reality is much different than this.
What constitutes a Systems Development project failure
The organization completely abandons the project at some point prior to its implementation.
The organization must rework a significant amount of the project, so much so that they deem it a failure but do go ahead and initiate the network.
The delivered Information Systems is okay, but the project was way over time and budget, therefore, it is defined a failure.
The delivered Information Systems doesn’t meet the user requirement or expectations, therefore; it is deemed a failure.
Functions of the Project Manager
Planning Project tasks and staffing the project team – a good manager always has a plan. The manager estimates resource requirements and formulates a plan to deliver the target system. Each task required to complete the project must be planned. Some of the planning issues include: How much time will be required? How many people will be needed? How much will the task cost? What tasks must be completed before other tasks are started? Can some of the tasks overlap?
Organizing and scheduling the project effort – members of the project team should understand their own individual roles and responsibilities as well as their reporting relationship to the project manager. The project schedule should be developed with an understanding of task time requirements, personnel assignments, and intertask dependencies.
Directing and controlling the project – once the project has begun the project manager becomes the project leader. As a leader the project manager directs the team’s activities and evaluates progress. The manager must frequently report progress to superiors. The manager’s job is to monitor tasks, schedules, and costs in order to control those elements.
Project Management Tools and Techniques
There are 2 commonly used Project Management tools:
Programme Evaluation and Review Techniques (PERT) charts which are most useful for project planning and modification.
Gantt charts which are for project scheduling and progress reporting.
Cont’ of Tools
A graphical representation of project tasks laid out in the form of a critical path network
Project tasks and their deviations in a bar chart format in the planning and estimating of a project prior to its inception.
Steps to Create a PERT Chart
Determine the duration time for each task
Assign a task identification letter to each task
Draw the PERT network, number each node.
Label each task with its task identification letter.
Connect each node from start to finish
And put each task’s duration on the network
Determine the need for any dummy tasks
Determine the earliest completion time for each task node
Verify the PERT network for correctness.
PERT Chart
Determine task dependencies
PERT network is continuously useful to project managers prior to and during a project.
PERT network is straightforward in its concept and is supported by soft war.
PERT network can be a valuable tool for project managers, but the tool is only as good as the data that are input to it. Its strengths includ
The PERT network’s graphical representation of the project’s critical path and task slack time allows the project manager to focus more attention on the critical aspects of the project-time, costs, and people.
The project management software that creates the PERT network usually provides excellent project tracking documentation.
The use of the PERT network is applicable in a wide variety of projects.
Weaknesses of the PERT network:
In order for the PERT network to be useful, project tasks have to be clearly defined as well as their relationships to each other.
The PERT network does not deal very well with task overlap. PERT assumes that following tasks after their preceding tasks end.
The PERT network is only good as the time estimates that are entered by the project manager.
By design, the project manager will normally focus more attention on the critical path tasks than other tasks, which could be problematic for near-critical path tasks if overlooked.
The Gantt chart
The Gantt chart is based on a two-dimensional graph scale.
Each of the significant project tasks is listed along the vertical axis of the graph, and the estimated elapsed calendar time to complete the entire project is listed along the horizontal axis.
An appropriate calendar time interval, such as days, weeks, or months is selected for the horizontal axis.
The Gantt chart is at its best for visually showing each of the project’s task status at any moment in time simply by drawing a vertical bar from top to bottom on the chart at the calendar time you are interested in.
Once drawn, a visual inspection of the shading within each of the bars on the chart gives you an indication of project task status for each task.
It is also useful for showing any overlapping or parallel tasks. It does not clearly show task dependence, even though it does show task start and stop times, and you can clearly see that tasks start
after others have already begun or are already finished.
Gantt Chart Strengths
Being able to see overlapping or parallel tasks.
Being able to see the status of each project task at any point in time.
Not being able to definitely tell from the Gantt chart whether the entire project is on time, behind time, or ahead of schedule.
Not showing task dependencies.