Explain System Analysis and Design

Unit 1: The Context of System Analysis and Design

Introduction

Systems are created to solve the problems. A system approach in any field can be defined as an organized way of dealing with a problem. A system can be defined as a collection of components that work together to achieve some objectives. Basically there are three major components in a system, input, processing and
output.

Fig: Basic System Components

System Analysis and Design (SAD) is a formal approach in system development that deals with systematic analysis of all the requirements and carrying out the systematic design taking into considerations of all the available resources.

System Development Life Cycle

         System Development Life Cycle is an organizational process of developing and maintaining systems. It helps in establishing a system project plan and also gives an overall list of processes and sub processes required for developing the system.

         System development life cycle means combination of various activities. In the System Analysis and Design terminology, the system development life cycle also means software development life cycle (SDLC.

Following are the different phases of system development life cycle:

1.   Preliminary study

2.   Feasibility study

3.   Detailed system study

4.   System analysis

5.   System design

6.   Coding

7.   Testing

8.   Implementation

9.   Maintenance

Fig: phases of system development life cycle

1.   Preliminary Study

Preliminary system study is the first stage of system development life cycle. This is a brief investigation of the system under consideration and gives a clear picture of what actually the physical system is. In practice, the initial system study involves the preparation of a‘ System Proposal’ which lists the Problem Definition, Objectives of the Study, Terms of reference for Study, Constraints, Expected benefits of the new system, taking the user requirements under considerations.

The system proposal is prepared by the System Analyst (who studies the system) and places it before the management. The management may accept the proposal and the cycle proceeds to the next stage. The management may also reject the proposal or re-quest some modifications in the proposal. In summary, we can say that system study phase passes through the following steps:

a.   problem identification and project initiation

b.   background analysis

c.    inference or findings (system proposal)

2.   Feasibility Study

If the system proposal from the preliminary study is accepted, the next phase is to examine the feasibility of the system. The feasibility study is basically the test of the proposed system in the light of its workability, meeting user’s requirements, effective use of resources and the cost effectiveness. These are categorized as technical, operational, economic and schedule feasibility. 

The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy to find the Return on Investment (ROI). The result is a feasibility report submitted to the management. This may be accepted or accepted with modifications or rejected. The system cycle proceeds only if the management accepts it.

3.   Detailed System Study

The detailed study of the system is carried out according the objectives of the proposed system. This involves detailed study of various operations performed by a system and their relationships within and outside the system. Interviews, on-site observation and questionnaire are the tools used for detailed system study. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration:

a.   Keeping in view the problems and new requirements

b.   Workout the pros and cons including new areas of the system

All the data and the findings must be documented in the form of detailed data flow diagrams (DFDs), data dictionary and logical data structures. The main points to be discussed in this stage are:

a.   Specification of the new system based on the user requirements.

b.   Functional hierarchy showing the functions to be performed by the new system and their relationship with each other.

c.    List of attributes of the entities

4.   System Analysis

Systems analysis is a process of collecting factual data, understand the processes involved, identifying problems and recommending feasible suggestions for improving the system performance. This involves studying the business processes, gathering operational data, understanding the information flow, finding out bottlenecks and evolving solutions for overcoming the weaknesses of the system so as to achieve the organizational goals. 

The major objectives of systems analysis are to find answers for each business process: What is being done, How is it being done, who is doing it, When is he doing it, Why is it being done and How can it be improved. The result of this process is a logical system design. Systems analysis is an iterative process that continues until a preferred and acceptable solution is found.

5.   System Design

Based on the user requirements and the detailed analysis of the existing system, the new system must be designed. This is the phase of system designing and is the most crucial phase in the developments of a system. Normally, the design proceeds in two stages:

a.   Preliminary or General Design

b.   Structured or Detailed Design

Preliminary or General Design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated.

If the project is still considered to be feasible, we move to the detailed design stage.

Structured or Detailed Design: In the detailed design stage, computer oriented work begins and the design of the system becomes more structured. Input, output, databases, forms, coding schemes and processing specifications are drawn up in detail. In the design stage, the programming language and the hardware and software platform in which the new system will run are also decided.

There tools and techniques used for describing the system design of the system are:

a.    Flowchart

b.   Data flow diagram (DFD)

c.    Data dictionary

d.   Structured English

e.   Decision table

f.     Decision tree

6.   Coding

The system design needs to be implemented to make it a workable system. This requires the coding of design into computer understandable language, i.e., programming language. This phase is also called the programming phase in which the programmer converts the program specifications into computer instructions. It is an important stage where the defined procedures are transformed into control specifications by the help of a computer language.

Generally, the programs must be modular in nature. This helps in fast development, maintenance and future changes.

7.   Testing

Before actually implementing the new system into operation, a test run of the system is done for removing the bugs. After coding the whole programs of the system, a test plan should be developed and run on a given set of test data. The output of the test run should match the expected results.

8.   Implementation

Implementation is the stage of a project during which program developed is turned into practice. The major steps involved in this phase are:

-          Acquisition and Installation of Hardware and Software

-          User Training

-          Documentation

9.   Maintenance

Maintenance is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environments. Errors are always found in the systems and they must be noted and corrected. The review of the system is done for:

-          knowing the full capabilities of the system

-          knowing the required changes or the additional requirements

-          Studying the performance.

A Framework for System Analysis and Design

Information System (IS) can be viewed as a tool that capture and manage data to produce useful information to support an organization and its employees, customers, suppliers and partners. Information system is an essential component in today’s working environment and it gives organizations the ability to compete with other businesses.

The ultimate objective of System Analysis and Design is to analyze the business requirements for information systems and to design the information system that can fulfill those requirements. In other words, the product of system analysis and design is the information system.

        The different types of Information system are

1.   Transaction Processing System (TPS): Transaction processing system process business transactions such as orders, payments, reservations, transaction cancellation etc. Example of TPS are Point of Sale (POS), School Billing System, and Online Transaction Processing (OLTP) etc.

2.   Management Information System (MIS): Management Information System uses the transactional data from the TPS to produce information needed by managers to run the business. Examples of MIS is Report Generation System, OLAP (Online Analytical Processing).

3.   Decision Support System (DSS): Decision Support System (DSS) helps the various decision makers to identify and choose the options and make appropriate decision. It helps to identify decision making opportunity or provides information to help make decisions. Example of DSS is data and knowledge mining systems.

4.   Executive Information System (EIS): Executive information system are designed especially for the business executives and managers for planning the business and assess performance according to the plans. Example of EIS include statistical data analyzer, stock exchange management system.

5.   Expert Systems (ES): Expert System capture and reproduce the knowledge of an expert problem solver or decision maker and simulates the thinking of that expert. Example of expert system include medical diagnosis system, airline simulation system etc.

6.   Communication and Collaboration System (CCS): The communication and collaboration system enhance the communication and collaboration between people in both internal and external environment. Example of CCS include TeamViewer, net meeting etc.

7.   Office Automation System (OAS): The office automation system help the employees of an organization to create and share documents that support day to day operations. Examples of OAS include office packages, offline file sharing system etc.

The Players-System Stakeholders

The players or the system stakeholders are the components or any individual, who contribute in developing an information system for an organization. The system analysts, information workers, expert systems, communication and collaboration system, office automation system can be classified as the system stakeholders.

A system analyst serves as a facilitator who bridges the communication gap between the non-technical system owners, users and the technical system designers. An information worker is any person whose job involves creating, collecting, processing, distributing and using information.

The players or system stakeholders of an organization’s information system can be broadly categorized as

1.   System Owners: System owners are the middle or the executive managers of an organization and they are more interested in the system cost rather than its operation. System owners try to figure out the value and the benefits the system will return to the business.

2.   System Users: System users are the information workers of an organization. They are less concerned with the cost and benefits of the system. They are concerned with the functionality of the system and the ease of its use. Their primary concern to get their jobs done. The different classes of system users are

a.   Internal System Users: They are the employees of the organization

                                                 i.    Clerical and Service workers

                                               ii.    Technical and Professional staff

                                              iii.    Supervisors, middle managers, and executive managers

b.   External System Users: They are people outside of an organization, but are related to the organization in a way or other

                                                 i.    Customers

                                               ii.    Suppliers

                                              iii.    Partners

                                              iv.    Sales Representatives

3.   System Designers

System designers are the technology specialists and they are interested in making choices of the technology and their uses. The system designers of an information system can be categorized as

                                                 i.    Database administrator

                                               ii.    Network architects

                                              iii.    Web architects

                                              iv.    Graphics designers

                                               v.    Security experts

                                              vi.    Technology specialists

4.   System Builders

System Builders are another category of technology specialists for information system and their role is to construct the system according to the system designer’s specifications. The system builders can be categorized as

                                                 i.    Application Programmers

                                               ii.    Systems programmers

                                              iii.    Database programmers

                                              iv.    Network administrators

                                               v.    Security administrators

                                              vi.    Webmasters

                                            vii.    Software integrators

5.   System Analyst

A system analyst serves as a facilitator who bridges the communication gap between the non-technical system owners, users and the technical system designers. A system analyst studies the problem and needs of an organization to determine how people, data, processes and information technology can best accomplish improvements for the business.

6.   External Service Provider

External Service Providers are the consultants from outside the organization who provide valuable suggestions and support for the information system to be built or in operation. Most external service providers are system analysts or designers who are contracted to give expertise or share their experience in the project. Examples of external service providers are technology engineers, system consultants, contract programmers etc.

7.   The Project Manager

A project manager is an experienced professional who plans, monitors and controls the project with respect to the schedule, budget, customer satisfaction, technical standards and quality. A project manager is the leader of the system building team and have some project management skills as well.

Business Drivers for Today’s Information System

In today’s business environment, a lot of issues and business trends are impacting the information systems. Many trends quickly becomes fad and many business trends doesn’t last for a longer period of time. Some of the major business drivers that impact the information system are:

1.   Globalization of the economy

Since 1990s, there has been a significant growth in the economic globalization with developing nations offering low-cost and high quality products. As a result, other nations had to compete with the developing nations to manage the economy of their own country. Because of this factors, information system and computer applications had to be internationalized. 

They were required to support multiple languages, currency exchange rates, international trade regulations, business cultures, and practices. Most information system require information integration for performance analysis and decision making. The language barriers, currency exchange rates all complicate information integration. Also there exist a problem for people to communicate in different languages.

2.   Electronic Commerce and Business

Electronic commerce is the buying and selling of goods and services by using the internet. Because of the rapid development in the internet technology and ecommerce, businesses around the world are changing and expanding their business model to adapt with the changing business environment. The internet is fundamentally changing the rules by which business is conducting and organizations are rapidly using the web interface as a suitable architecture for conducting day-to-day business within and outside the organization.

3.   Security and Privacy

With the development in internet technology, there is a greater risk of security issues for today’s business organizations. Businesses need to protect their digital assets and information from unauthorized access and they also need to maintain the privacy of their customers and other information. Moreover, government rules and policies are changing as per the changes in the digital technology and new security threats are introduced every day. Businesses need to adapt with the changing security issues in order to continue their business.

4.   Collaboration and Partnership

Collaboration and partnership has been a significant business trends in today’s businesses. Organizations are encouraging to create cross functional teams like engineering, marketing, sales, manufacturing, inventory, and distribution and information systems to collaborate with each other to achieve the common organizational goals. Similarly, collaboration and partnerships are extending between organizations, sometimes even between competitors. 

Organizations with common businesses are merging and some are collaborating to create a common solution for mutual benefits. For example, Microsoft and Oracle collaborate to create a common database solution that runs Oracle database on a windows platform.

5.   Knowledge Asset management

Knowledge is the result of processed information. As the raw data are processed, it becomes information. When the valuable information is processed, it becomes knowledge which is vital for an organization to gain a competitive advantage over their competitors. Data and information may be redundant and contradictory, as a result of which, the derived knowledge may be inappropriate.

6.   Continuous Improvement and Total Quality Management

Information systems automate and support business processes. To continuously improve the business process, continuous process improvement (CPI) may be used to implement a series of small changes for improvement. Such changes can result in cost reduction, improved efficiencies and increased value and profit.

Moreover, Total Quality Management (TQM) has been a major business driver for facilitating quality improvements and management within a business. TQM recognizes everything in the business as responsible for quality.

7.   Business Process Redesign

Business Process Redesign (BPR) is the study, analysis and redesign of fundamental business processes to reduce cost and to improve the value added to the business. BPR involves making changes to business processes across a larger system. Business Processes are carefully documented and analyzed for timeliness, bottlenecks, costs and the strategies as well. Business processes are then redesigned for maximum efficiency and at the lowest possible costs.

       

Technology Drivers for Today’s Information Systems

The rapid development in information technology plays a vital role in the development and usage of the information systems. As the technology gets outdated, they can give significant problems in information systems. The technologies that are influencing the information systems are:

1.   Networks and the internet

Most information systems operate in a networked environment and most corporate network are nowadays connected to the internet or they are dependent to the internet in one way or another. People working on the information system should be aware of the internet technologies like HTML, XML, Scripting language, JAVA, Intranet, Extranet, Web services etc.

2.   Mobile and Wireless Technologies
Mobile and Wireless Technologies also plays a crucial role in bringing significant changes in information systems development and usage. Handheld devices with wireless connectivity like tablets, PDAs, mobile devices, smartphones and laptops are commonly used in most organizations. Such trends in makes a significant impact in the analysis and design of the new information systems. While designing information systems, the limitations of mobile devices and screen sizes must be considered.

3.   Enterprise Applications
Most of the organizations requires a set of enterprise applications like financial management, human resources management, marketing and sales, operations management etc to conduct business. Organizations may need applications like ERP (enterprise resource planning) and SCM (Supply chain Management) to operate their daily businesses. Such applications should be taken into considerations while developing information systems for an organization.

A simple system development process

The system development process consists of a standard set of processes that is followed for developing a project or system. The system development process always follows a problem solving approach and consists the following steps:

1.   Identify the problem

2.   Analyze and understand the problem

3.   Identify Solution requirement and expectations

4.   Identify alternative solutions and choose the best course of action

5.   Design the chosen solution

6.   Implement the chosen solution

7.   Evaluate the results

The steps involved in system development process can be summarized as

1.   System Initiation

2.   System Analysis

3.   System Design

4.   System Implementation

5.   System Support and Continuous Improvement

Unit 2: Information System Building Block

Introduction

An information system is the main tool that serves the goal of an organization. It is more than just a technology and should cover a wider range of perspectives. From a user’s point of view, an information system is considered as a processing system that manipulate data in forms and reports, from a manager’s point of view, an information system is considered as a tool to create strategic plans and competitive edge and from a developer’s point of view, it is considered as a system developed by programming languages, networking technologies and databases.

In this regard, we can conclude that the building blocks of an information system are the core elements that interact with each other for the flow of data and information across the organization.

The Product Information System

Most organizations are served by a collection of information systems that support various functions. Organizations have the front office information system that support business functions that facilitate services to the customers and the back office information system that support internal business operations as well as interact with suppliers.

Both the front office information system and the back office information systems feed data to management information systems and decision support systems that support management needs of the business.

 Most information systems communicate with customers and suppliers using the electronic commerce technology, customer relation management (CRM) and supply chain management (SCM) applications. Most of the organizations also have an intranet to support communications between employees and the information systems.

A framework for system development architecture

Any information system is built with the base of certain architecture like the database architecture, application architecture, network architecture and the software architecture. 

The basic information system architecture serves as a higher level framework for understanding the different views of the building blocks of an information system. 

The information system architecture provides a foundation for organizing the various components of any information system that we are trying to develop.

The system development architecture can be viewed from different perspectives. From the viewpoint of the owner, the goal oriented perspective of an information system include

-          The goal to improve the business knowledge

-          The goal to improve business processes and services

-          The goal to improve business communication and collaboration

From the system designers’ perspective, the information system should focus on

-          The database technologies that support the business data and knowledge

-          The software technologies that automate business process and service

-          The interface technologies that support business communication and collaboration.

Based on these factors the building blocks of an information system can be categorized as

1.   Knowledge Building Blocks

The business knowledge is derived after refining and processing the data and information. Knowledge enables a company to achieve its mission and vision. The system owners, system users, and the system designers may have different perspectives and views of the knowledge.
The system owner may be interested in those information that adds new business knowledge to make intelligent business decisions that support the organization’s mission and the goals.

The system users need knowledge about the data that describes the business. They may need to know about customer’s information like name, address, telephone number etc and the information about the products and services. The system users also need to provide data that are consistent and relevant to the information and vision provided by the system owners.

The system designer is more concerned with the database technology and the interface technology to be used. They should have the clear view of the SQL and the reports that are to be provided for the

businesses.

2.   Process Building Blocks

The fundamental goal of an information system is to improve the business and services processes. The business process represent the work in a system and people and computers both perform different processes. 

The business process building blocks are also different for system owners, the system users and the system designers.

The system owners are more interested in the reports of high level business functions like sales, services, manufacturing, shipping, receiving and accounting. The system owners need not just the single functional information system but the cross functional information system that support many business functions like sales and the order information system.

Similarly the system users are more concerned with the work that must be performed to provide responses to the business events like sales, inventory, purchases etc.

From the system designer’s point of view, the business processes is constrained by the limitations of specific application development technologies like JAVA, C++, C# etc. The designer’s view is always technical and focuses on which software technology to use, how to determine business process and which architecture to use to address the process.

3.   Communication Building Blocks

The common goal of an organization is to improve the business communication and the collaboration between employees and other core elements. Information systems should provide effective and efficient communication interface to system users to promote teamwork and coordination of activities. The information system must provide a medium to communicate with other information systems available in an organization.

A system owner may need to know about which business unit, employees, customers and external businesses must use the system interface. They may need communication regarding the location of businesses and requirement with other information systems.

A system user’s view of communication is more concerned with the inputs and outputs of the system. The input and the output represent how the information system interact with users, employees, customers and other businesses.

System designers are more concerned about the technical communication regarding the specifications and the modules of the system that is being built.

Network Technologies and the IS building blocks

Most information systems developed nowadays are built considering the use of computer networks. The same information system is run on multiple computers across an organization on the foundation of computer networks. 

The basic building blocks of information system, knowledge, process and communication are all based on the foundation of networks. We can also separate the building blocks and force them to communicate across the network.

 Organizations may use an intranet to support the communication between processes and various networking technologies may be implemented to create such a communication subsystems.

               Unit 3: Information Systems Development

The Process of System Development

Information system development always require to follow some standardized processes. An information system developed using a standardized process can provide organizations with improvement in productivity within a shorter period of time. 

Using a standard and consistent process for system development creates efficiencies and reduces the maintenance costs which ultimately can improve the quality and productivity as a whole. Standardized system development process like the Capability Maturity Model are widely used nowadays in developing most of the information systems.

The Capability Maturity Model

The capability maturity model (CMM) is a standardized framework for analyzing the maturity level of an organization’s information systems development and management processes and products. The CMM was developed by the Software Engineering Institute at the Carnegie Mellon University that assumes as an organizations’ information system matures, the project timelines and cost reduces, while productivity and quality improves. 

The CMM framework for systems and software is intended to help organizations to improve the maturity of their systems. The CMM consists of the following five levels of maturity.

1.   Level 1: Initial

This level is also called anarchy and system development doesn’t follow any consistent process. Each development team uses its own tools and methods and success or failure is a function of the skill and experience of the team. The process is always unpredictable and encounters many problems and are usually behind schedule. Almost all the organizations start at level 1.

2.   Level 2: Repeatable

In the second level, the project management processes and practices are established to track project costs, schedules and functionality. A system development process is always followed and success or failure is still a function of the skill and experience of the team. A concerned effort is always applied to get the project success.

3.   Level 3: Defined

In this level, a standard system development process or methodology is purchased or developed and all the project use this process to develop and maintain information systems and software. As a result the project is more consistent and has a high quality documentation and other outputs. The process is stable, predictable and repeatable.

4.   Level 4: Managed

In this level, measurable goals for quality and productivity are established. The measures of the standard system development process and product quality are collected and stored. Management is more proactive to system development problems. If problems are encountered, the process is adjusted based on the predictable and measurable features.

5.   Level 5: Optimizing

In this level, the standardized system development process is continuously monitored and improved on the basis of measures and data analysis established in earlier levels. This includes changing the technology, using best practices to perform activities, and adjusting the process itself. Lessons learned are shared across the organization to eliminate inefficiencies and to improve quality. 

Life Cycle versus Methodology

Most system users and developers incorrectly think that the terms system life cycle and methodology are similar and can be interchanged. The system development processes or methodology are derived from a natural system life cycle. 

The system life cycle is discovered after any two key events trigger changes from one stage to another. Based on the stages of the system development life cycle, a methodology is derived. The methodology may be different for different stages of the life cycle.

Methodology can be purchased from external sources or they can be developed within an organization. The system life cycle is recorded as changes are seen from one stage to another, but methodology is derived for the individual stages. 

Underlying Principles for System Development

        The general principles for system development are:

1.   Get the system users involved in system development

2.   Use a problem solving approach

3.   Establish phases and activities

4.   Create Documents throughout the development

5.   Establish Standards

6.   Manage the process and projects

7.   Justify information system as capital investments

8.   Don’t be afraid to cancel or revise scope

9.   Divide and conquer

10.        Design systems for growth and change

Where do system development projects come from?

Most of the projects are initiated by the system owners and the system users. The foundation of any project is the combination of problems, opportunities and directives. As a way or another, the aim of the project is always to solve the problems. Problem solving is the act of rectifying errors, exploiting opportunities and to fulfill directives. According to James Whether be, a problem can be classified as PIECES, that is

P: the need to correct or improve performance
I: the need to correct or improve information
E: the need to correct or improve economics, control costs and increase profits

C: the need to correct or improve control or security

E: the need to correct or improve efficiency of people and processes

S: the need to correct or improve service to customers, suppliers, employees etc

        Projects can be either planned or unplanned

        Planned projects is the result of one of the following

-          An information system strategy plan which identifies the system development projects that will return some value to the business

-          A business process redesign to eliminate redundancy and to improve efficiency and value. A new information system may be needed for the redesigned business processes.

The unplanned projects are those that are started by a specific problem, opportunity or directive that occurs in the course of doing business. Anyone in an organization can submit or propose a project based on the requirement of the business. A special steering committee of system owners and IT managers receive such proposal and approve if required for the business. 

The FAST phases

Framework for the Application of Systems Thinking (FAST) is a hypothetical methodology used to demonstrate a system development process. It is not a commercial methodology, but still is a flexible method to provide a representation of system for different types of projects and strategies.

The FAST methodology consists of the following eight phases

1.   Scope Definition

The scope definition is the first phase of the project and it analyses the problem definition and finds out the answers to whether the problem is worth looking or not. It establishes the size and boundaries of the project, the project vision, any constraints or limitations, required number of project members, the budget and the schedule.

Primarily, the system owners, project managers and the system analysts are the participating members of the project scope definition.

2.   Problem Analysis

The problem analysis phase studies the existing system and analyses the results to provide a better understanding of the problems that triggered the project. The analysis in this phase answers whether the benefits of the solving the new problems will exceed the cost of building the new system or not. The system owners, project managers and the system analyst are the major participants of this phase.

The main reason of performing the problem analysis phase is to set the system improvement objective after a detail understanding of the existing problems.

3.   Requirement Analysis

The requirement analysis phase defines and prioritizes the business requirements. This is the most important phase that finds out what the users need from the new system. The technology that is used and the technical implementation is not discussed in this phase. The system analyst works closely with the system users to identify needs and priorities. This information is collected by interviews, questionnaires, and meetings.

The system users, system analyst and the system owners are the major participants of this phase.

4.   Logical Design

Once the business requirements are identified, they are designed logically as system models to validate the requirements for their completeness and consistency. The DFD is an example of the logical design. The primary objective of logical design is to translate the business requirements into system models.

The system users, system analyst and the system managers are the major participants of this phase.

5.   Decision Analysis

Once the business requirements are identified and a logical design is also modeled, the next phase is to perform a feasibility study. The decision analysis phase first identifies the technical solutions, analyze them for feasibility and recommends a system to be designed. Each of the solutions identified are evaluated by the following criteria

a.   Technical feasibility

b.   Operational feasibility

c.    Economic feasibility

d.   Schedule feasibility

e.   Risk feasibility

The system designers, system analyst and the system owners are the major participants of this phase. 

6.   Physical Design and Integration

Once the system design is approved, the system can now be finally designed. The purpose of the physical design and integration phase is to transform the business requirements into physical design specifications that will guide the system construction. The physical design also addresses the issues like the technical design standards to ensure the completeness, usability, reliability, performance and quality. The system designers and the system analysts are the major participants of this phase.

7.   Construction and testing

Once the physical design is initiated, the construction of the system can begin and the system components can be tested as well. The system builders, designers, analysts, users and the managers are the major participants of this phase. Various databases, software packages, and user/system interfaces need to be installed during this phase. The purpose of the construction and testing phase is

a.   To build and test a system that fulfills the business requirements and physical design specifications

b.   To implement the interfaces between the new system and the existing systems

8.   Installation and delivery

The installation and delivery phase serves to deliver the system into operation. The functional system is installed by the system builders, the system users are trained by the system analyst. The manuals are also prepared, existing files and databases are converted to adapt the new system and the final system testing is performed.

Cross Life Cycle Activities

System development also involves a number of cross life cycle activities that are vital to the success of any project. The major cross life cycle activities in system development are

1.   Fact Finding

2.   Documentation and Presentation

3.   Feasibility Analysis

4.   Process and Project Management

Sequential versus Iterative Development

Alternative Route and Strategies for System Development

1.   Model Driven Development Strategy

A system modeling is the oldest and most commonly used approach to analyze and design the information systems. A system model is a picture of a system that represents a desired reality and can facilitate the communication between users, analysts, builders and the managers. In the FAST methodology, the system models are used to illustrate and communicate the knowledge, process and interface of information system. This approach as a whole is known as the model driven development.

Advantages of Model Driven Development Strategy

1.   Requirement specifications are more straightforward and better documented

2.   Business requirements and system designs are easier to validate with pictures than words

3.   It is easier to identify and analyze alternative technical solutions

4.   Design specifications are more stable adaptable and flexible.

5.   System can be designed correctly with the help of the model.

Disadvantages of Model Driven Development Strategy

1.   It is time consuming. It takes a lot of time to collect the facts, draw the models and to validate them.

2.   The models can be good only if the users have better understanding of the system

3.   The models reduces the user’s role in the participation of the system development

4.   Sometimes the model driven approach is not flexible.

2.   Rapid Application Development Strategy (RAD)

        The RAD strategy is the popular approach of system development and the basic ideas of RAD are

1.   To involve system users in the analysis, design and construction of the system

2.   To organize system development in a series of focused workshops involving system owners, users, analysts, designers, and builders

3.   To speed up the requirement analysis and design phase through an iterative construction approach

4.   To reduce the time taken to build the complete system

The basic principle of RAD is to create a prototype of the working system. Since the emphasis of RAD is on reducing the time in development, the initial problem, requirement and decision analysis phases are combined and accelerated. 

The logical and physical design phases are also treated as a single phase and it is also accelerated. In each of the phases, a prototype is created and tested. A technical feedback of the tested prototype is analyzed and the system is revised with respect to the requirements and the objectives of the system. Finally a complete system is tested and placed into operation.

Advantages of Rapid Application Development Strategy

1.   Useful in projects where the user requirements are uncertain

2.   Encourages user and management participation

3.   Projects have higher visibility and support because of the active involvement of users

4.   Errors are detected early in the prototypes

5.   It is easier to test the prototypes of the system rather than to test the whole system.

Disadvantages of Rapid Application Development Strategy

1.   The approach is expensive to operate, support and maintain the system

2.   Since problem and requirement analysis are ignored, the prototype may be working on wrong problems

3.   A RAD based prototype may discourage analyst from considering other technical alternatives

4.   The emphasis on speed may impact on quality of the system

5.   The system owners may not agree to discard the prototypes that are totally useless

3.   Commercial Application Package Implementation Strategy

Sometimes it is easier and efficient to buy and implement an information system than to build the system. For applications like human resource management, accounting, procurement, manufacturing and distribution, organizations can purchase and implement commercial application package. The complete commercial solution is the enterprise resource planning (ERP) that provides all the information system applications for an entire business. The commercial ERP may costs a lot of amount but require a small number of managers and users to implement.

Advantages of Commercial Application Development Strategy

1.   New systems can be quickly implemented because programming is not required

2.   New staffs and expertise is not required to develop the system

3.   Costs in improvement in features, capability and usability are decreased as these tasks are performed by the application vendor themselves.

4.   The application vendor takes the sole responsibility for the system improvement and error corrections

Disadvantages of Commercial Application Development Strategy

1.   The successful implementation of commercial application depends on the long term success and reliability of the system and the organization as well

2.   The purchased system may not give the ideal solution as expected by the management and the users

3.   Some users may be reluctant to use the new system as compared to the existing systems.

4.   Some of the commercial applications may not be customized to meet the requirements and it may be too expensive.

Hybrid Strategies

Organizations may also use the combination of different strategies to develop and implement an information system. The model driven approach and the rapid application development process can be applied at once to develop and implement the system. This hybrid strategy is known as an incremental strategy.

Automated Tools and Technology

Nowadays a large number of automated tools are developed to assist system developers in developing new information systems. Some of the advantages of using automated tools in system development are

-          Improved productivity through automation of tasks

-          Improved quality as automated tools check the completeness, consistency and contradictions of systems

-          Better and more consistent documentation

-          Reduced time in maintenance

The different automated tools are

1.   Computer Aided System Engineering (CASE)

CASE is the use of automated software tools that support the drawing and analysis of system models and the associated specifications. Some CASE tools also provide prototyping and code generation capabilities. Computer Aided Design (CAD) is an example of the CASE tool that is used to design products like vehicles, structures, machines and furniture.

Most CASE tools include the following elements

a.   CASE repositories: it is at the center of the CASE architecture that serves as the developer’s database. It also consists of tools for creating system models and documentation

b.   CASE facilities: it includes facilities like

§  diagraming tools: for drawing models

§  dictionary tools: to record, delete, edit, and output the documentation and specifications

§  design tools: to develop samples of system components

§  quality management tools: to analyze system models, completeness, consistency

§  documentation tools: to assemble, organize and report the system models

§  code generator tools: to automatically generate database and application programs

§  testing tools: to simulate the operations and the problems

c.    Forward and reverse Engineering: The CASE tools also provide the forward and reverse engineering approach of system modeling. The system can be developed all the way from the initial design to the implementation as well as redesigning the system from the end point.

2.   Application Development Environment

Application Development Environment (ADE) is an integrated software development tool that provides all the facilities necessary to develop new application software with maximum speed and quality. The ADE can be said as an improvement to RAD, and they make the programming simpler and more efficient. Most of the programming language compilers are not integrated into an ADE and some examples of ADE are JAVA, ColdFusion, .NET etc. The following facilities are provided by the most ADEs

-          Programming language and interpreters

-          Interface construction

-          Middleware

-          Testing tool

-          Version control tools

-          Help authoring tools

-          Repository links

3.   Process and Project managers

The process manager tool is an automated tool that helps to document and manage the methodology, its deliverables, and quality management standards. The project manager tool is an automated tool that helps to plan system development activities, estimate and assign resources, schedule activities and resources, monitor progress, control and modify schedule and resources. 

The process and project management tools helps us to manage the system development methodology and projects that use the methodology. These tools are used to support the cross life cycle activities of a system. Microsoft project is a good example of process and project management tool. 

Unit 4: System Analysis

What is System Analysis?

System Analysis is a problem solving technique that decomposes a system into its components for analyzing how well the components work and interact to accomplish the purpose. In other words, it is the study of the system and its components. System Analysis is an essential phase without which the system design phase cannot be initiated. The system analysis focuses on business issues rather than the technical and implementation issues.

The system analysis phase is driven by the business concerns the system owners and the system users which addresses the knowledge, process and the communication building blocks. The system analysis is done by the system analysts.

System Analysis Approaches

The fundamental objective of system analysis is problem solving and there are many approaches of system analysis. The different approaches are viewed as competing alternatives and certain combinations are also implemented. Following are the different approaches of system analysis:

1.   Model Driven Analysis Approach

The model driven analysis is a problem solving approach that focuses on the graphical system models to document and validate existing or proposed systems. Ultimately the system model becomes the blueprint for designing and constructing an improved system. It uses pictures to communicate business problems, requirements, and solutions.

Structured Analysis, Information Engineering and Object Oriented Analysis are the examples of model driven analysis. Flowcharts, Hierarchy Charts and Organization charts are the examples of pictures used in model driven analysis approach.

Structured Analysis is used to analyze an existing system or define business requirements for a new system. It is one of the widely used model driven approach that focusses on the flow of data through business and software processes. It is a process-centered method that uses data flow diagram to model the different processes of the system.

Information Engineering is a model driven, data-centered and process sensitive technique for planning, analyzing and designing information systems. By process sensitive, it means that the IE is less focused on processes. The information engineering (IE) models are the pictures that illustrate and synchronize the system’s data and processes. The key tool used to model data requirement in IE is the entity relationship (E-R) diagram.

Object Oriented Approach integrates data and processes intro constructs called objects and the object models illustrate the system objects from various perspective like structure, behavior and interactions of the objects. It views information systems not as data and processes but as a collection of objects that encapsulate data and processes.

2.   Accelerated System Analysis Approach

The accelerated system analysis approach focus on the construction of prototypes of system to rapidly identify business and user requirements for a new system. Prototype is a small and incomplete but working sample of a desired system. This approach is also referred to as the rapid application development approach (RAD) using which systems can be developed quickly and quickly identify the crucial business requirements. 

The accelerated system analysis approach focuses on the communication building block of information system and at the same time also address the data and process building blocks.

Discovery Prototyping and Rapid Architected Analysis are the examples of accelerated system analysis approach.

Discovery Prototyping is used to identify the user’s and business requirements by having them to react to a quick implementation of those requirements. It uses the rapid development technology and discourage users to the final look of the system. It uses a simple development tool like Microsoft Access to rapidly create a simple database, user input forms and sample reports.

Rapid Architected Analysis using reverse engineering

3.   Requirement Discovery Methods

Fact Finding

Joint requirement Planning

4.   Business Process Redesign Methods

TQM, CPI

5.   FAST System Analysis Strategies 

Unit 5: Fact Finding Techniques for Requirements Discovery

An Introduction to Requirements Discovery

To develop a system, we must be able to identify, analyze, and understand the user requirements and the system requirements. The process and techniques that a system analyst uses to identify, analyze and understand system requirements are referred to as requirement discovery.

System Requirements specify the property and quality that an information system should have. System requirements that specify what the information system must do is referred to as functional requirement, while non-functional requirements specify the property and quality of the system.

Essentially, the purpose of requirement discovery is to correctly identify the knowledge, process and communication requirements for the users of a new system. Failure in identifying the requirements may result to following issues

-          The system may cost more than the estimated cost

-          The system may be delivered much later than the estimated time

-          The system may not meet the user’s expectations

-          The cost of maintaining and operating may be very high

-          The system may be unreliable and may have errors

-          The reputation of the organization may also get worse

Because of these reasons, while defining system requirements, it is important that they meet the following criteria       

-          Consistent: the requirements should not be conflicting

-          Complete: the requirements should describe all possible inputs and responses

-          Feasible: the requirements should be satisfied based on the available resources

-          Required: are the requirements truly needed

-          Accurate: are the requirements correctly stated

-          Traceable: do the requirements directly map to the functions and features of the system

-          Verifiable: can the requirements be demonstrated during testing

The process of Requirement Discovery

        The process of requirements discovery consists of the following activities:

1.   Problem Discovery and Analysis

A system analyst should be able to identify the root cause of a problem. A problem may be caused by different reasons and each reason may have different solutions. But applying different solutions to solve the problems may not solve the root cause of the problem. As a result, they may design and implement a solution that may not solve the real problem or may cause new problems.

A popular tool used to identify, analyze and solve problem is the Ishikawa diagram, introduced by Kaoru Ishikawa of Kawasaki shipyard in Japan. Ishikawa diagram is a fishbone-shaped graphical tool used to identify, explore and represents the problem and the causes and effects of those problems. It is also referred to as cause-and-effect diagram. The Ishikawa diagram begins with the name of the problem at the right side and the possible causes and effects are drawn as bones from the backbone pointing with an arrow.

Fig: a simple Ishikawa diagram

2.   Requirements Discovery

Once the problems of a system domain is well understood, the system analyst can start to define the requirements. System Analysts should have adequate knowledge about the fact-finding technique that is used across the entire development cycle. The fact-finding technique is extremely important in the requirement analysis phase that tries to collect all the possible requirements of the system development process. 

Once the fact-finding process it completed, tools like use case, data models, process models and object models can be made to draw conclusion of those facts. Fact-finding is the most critical phase in requirement discovery to identify information, functional and communication vision, and to identify the business knowledge process.

  

3.   Documenting and Analyzing Requirements

Once the fact-finding process is started, system analyst starts to collect and document the information in an organized and meaningful way. The documentation of the facts provide direction for analyzing the requirements and to determine the correct requirements of the system. Once all the requirements are identified, the system analyst formalizes them by presenting in a document that will be reviewed and approved by the users and the owners.

The documentation of the facts and the requirements goes through the following activities

-          Documenting the draft requirements

The initial findings are recorded in a draft form. The use case diagrams, decision tables and requirement tables are used to document the system functions, business policies, decision making rules and the specific requirements of the system.

-          Analyzing the requirements

The primary objective of requirement analysis is to discover and solve the various problems of the initial requirements that are collected. It analyzes the initial requirement comparing with the following list of problems

o   Missing requirements

o   Conflicting requirements

o   Infeasible requirements

o   Overlapping requirements

o   Ambiguous requirements

-          Formalizing Requirements

The system requirements are documented in a formalized way and they are presented to the system users and the owners. This document serves as a formal contract between the system owners and the document team. 

The formal document is also referred to as a requirement statement, requirement specification or the requirement definition. Most companies, uses the document format and the naming conventions used in such formal documents while preparing other documents as well. 

The requirement statement finally serves as a formalized standard and a document format for the future documentation of the organization.

4.   Requirements Management

The requirements of a system changes and new requirements may arise even after documenting all the possible requirements. 

To solve the problems caused by new and changing requirements, it is necessary to perform the requirement management, which is the process of managing changes in the requirements. 

It consists of procedures, policies and processes to handle the change in requirements. It specifies how a change should be submitted, how it is analyzed for impact to cost, schedule and scope, how it is approved or rejected, and how the change is implemented if approved.

  

Fact Finding Techniques

        The different fact finding techniques are

1.   Sampling of existing documentation, forms and files

2.   Research and site visits

3.   Observation of the work environment

4.   Questionnaires

5.   Interviews

6.   Discovery Prototyping

7.   Joint Requirements planning

1.   Sampling of existing documentation, forms and files

Initially, System analyst should get the facts from the existing documentation rather than asking the people.

The system analyst should collect the facts from the following types of documents

-          Memos, studies, minutes, suggestion box notes, customer complaints, reports

-          Accounting records, performance reviews, and their reports

-          Information system project requests

2.   Research and Site Visits

3.   Observation of Work Environment

-          Collection of facts by observing people at work

4.   Questionnaires

Free format questionnaires

Fixed format questionnaires

5.   Interviews

Unstructured interview: involves asking general questions and may get off track from the objective. Are usually not used in system analysis and design.

Structured Interview: involves asking specific questions regarding the objective of the interview.

Open ended questions and closed ended questions

6.   Discovery Prototyping

Mostly used in cases where the development team is having problems in defining system requirements. The philosophy of discovery prototyping is that users will recognize and identify their requirements when they see them.

7.   Joint Requirements Planning

It is a process where highly structured group meetings are conducted for analyzing problems and defining the requirements.

It is a team approach and generally requires extensive training of the members. JRP is becoming popular in system planning and analysis to obtain acceptance on problems, objectives and requirements.

The following are the participants of a JRP session

-          Sponsor: single person, who is in top management. Starts the meeting and also gives closing remarks

-          Facilitator: single person who plays the role of leader. Leads all sessions, and has excellent communication, negotiation, business and organization skills.

-          Users and Managers

-          Scribes: people responsible for keeping records of everything discussed in the meeting. The records are later published

-          IT Staff: do not speak until invited to speak.

Unit 6: Modeling System Requirements with Use Cases

An Introduction to Use-Case Modeling

In order to successfully plan, analyze, design, construct and implement an information system, the system analyst should understand the needs of the users and the owners and also need to understand the reasons why the system is being developed. This approach is also referred to as user-centered development.

By focusing on the users of the system, the analyst can concentrate on how the system will be used but not how it will be constructed. Use-case modeling is an approach that facilitates usage-centered development. Use case modeling is the process of modeling a system’s functions in terms of business events, who initiated the events and how the system responds to those events.

The concept of use case modeling was initiated by Dr. Ivar Jacobson in 1986, as a framework for object oriented methodology for developing information systems. Use case modeling is widely used for defining, documenting, and understanding an information system’s functional requirements.

Use case modeling facilitates and encourages user involvement in system development. Some of the benefits of use-case modeling are as follows:

1.   Provides a tool for capturing functional requirements

2.   Assist in decomposing system scope into more manageable pieces

3.   Provides a means of communicating with users and other stakeholders

4.   Provides a means for identifying, assigning, tracking, controlling, and managing system development activities.

5.   Provides a means for estimating project scope, effort and schedule.

6.   Provides a framework for testing in terms of defining test plans and test cases

7.   Provides a framework for user help systems, and documentation

8.   Provides a tool for requirement traceability

9.   Provides functional specifications for designing user and system interfaces

10.                Provides a means for defining database access requirements in terms of adds, changes, deletes and reads

System Concepts for Use-Case Modeling

A use-case modeling includes the following components:

1.   Use Cases

Use case modeling identifies and describes the system functions by using a tool called the use cases. They describe the system functions from the perspective of external users and the terminologies they understand.

Use cases are represented graphically by a horizontal ellipse with the name of the use case. It represents a single goal of the system and describes the sequence of activities and user interactions. Use cases are initially defined during the requirement analysis stages and are also refined throughout the other stages of the life cycle.

2.   Actors

Use cases are usually initiated by the external users called the actors and all the system activities are started by the actors to complete the business tasks that produce something of measurable value. An actor doesn’t necessarily need to be an individual. It can be an organization, another information system, or an external device. An actor is represented graphically as a stick figure labeled with the name of the role the actor plays.

                                       

                                       Actor Symbol

Generally, there are four types of actors:

a.   Primary Business Actor: they are the individuals that primarily benefits from the execution of the use case by receiving something of measurable or observable value. The primary business actor may or may not initiate the business event. Staffs of an organization receiving a paycheck are primarily benefited by the event but do not initiate the process of payment.

b.   Primary System Actor: they are the individuals that directly interface with the system to initiate the business or system event. They may interact with the primary business actor for the purpose of using the actual system. They facilitate the event through the direct use of the system for the benefit of the primary business actor. For example, a bank teller who processes a banking transaction in a banking information system is a primary system actor.

c.    External Server Actor: they are the individuals that responds to a request from the use case. They initiate an action that may or may not benefit the primary business or system actors and the action is initiated as per the request or service forwarded by the system. For example, the credit department of a bank authorizing the charge for services through transactions made by the credit card.

d.   External Receiver Actor: the individual that is not the primary actor but receives something of measurable or observable value from the use case. For example, a store manager receiving an order to package a product after the customer has made an order.

3.   Relationships

A relationship is represented with a line between two symbols in a use-case diagram. The different types of relationships are

a.   Associations: It is a relationship between an actor and a use case whenever they interact with each other. Associations can be unidirectional or bidirectional. 

b.   Extends: The extends relationship is used to expand the functionality of the initial use case. The extends relationship is usually identified in the analysis phase. 

c.    Uses: Also known as includes, the uses relationship that reduces redundancy among two or more use cases by combining the common steps found in those cases. 

d.   Depends on: A depends on relationship indicates that one use case cannot be performed until another use case has been performed. It is labeled as <<depends on>>. It provides a model for planning and scheduling of system development. 

e.   Inheritance: The inheritance relationship is initiated when two or more actors share common behavior. A single actor plays the role of multiple actors in an inheritance of use cases.

The Process of Requirements Use Case Modeling

1.   Identify the business actors

2.   Identify business requirements use cases

3.   Construct use case model diagram

4.   Document business requirements use case narratives

Use Cases and Project Management  

Unit 7: Data Modeling and Analysis

What is Data Modeling?

Data Modeling is a technique for organizing and documenting a system’s data. Data modeling is also referred to as database modeling. An entity relationship diagram (ERD) is a simple example of data modeling.

The Entity relationship diagram represents data in terms of the entities and the relationship as described by the data. Some of the elements of the ER diagram are

1.   Entities:

Entity is a class of persons, places, objects, events or concepts about which the data needs to be captured and stored. Any particular object that has some data is an entity and an entity identifies a specific class of object and is different from other types of entities. In an ER diagram, an entity is represented by a rounded rectangle.

2.   Attributes:

Attributes are the description or characteristics of the entities. They define the properties of the data of an entity. A data type is an attribute that defines what type of data can be stored. Some of the data types that can be used are number, text, memo (same as text but with defined size), date, time, yes/no value, image etc.

3.   Relationships:

The entities and attributes do not exist without the relationship between them. A relationship is an association that exist between two or more entities. The relationship may represent an event that links the entities or just exist between the entities.

The Process of Logical Data Modeling

Data modeling is performed during various types of projects and in multiple phases of projects. Data modeling is a progressive technique and there is no final data model for a business or application.

 A data model is always considered as a living document that changes with response to a changing business. Data models should be stored so that they can be retrieved, expanded and edited in future time.

The different data modeling process in system planning and analysis include the following

1.   Strategic Data Modeling

Many organizations select application development projects based on the strategic information system plans and strategic planning is a separate component in most of the organizations. Strategic planning produces an information system strategy plan that defines the overall vision and architecture for information systems. Most strategic data modeling approach includes the enterprise data model. Information engineering is the methodology that uses this approach.

The enterprise data model identifies only the fundamental entities but are not defined in terms of their key attributes and even the relationships may not be defined. The enterprise data model is stored in the corporate repository and used whenever the application development project is started.

2.   Data Modeling during system analysis

During the system analysis, the focus is more on the logical data modeling and the result is usually the application data model. The data model for a single information system is known as an application data model.

Data models are usually not constructed during the scope definition phase or any other problem analysis phase. 

The short duration of those phases makes the model impractical. A context data model may come into effect during the problem analysis phase. A context data model is a data model that includes the entities and relationships but no attributes. It is during the requirement analysis phase that a logical data model is developed under the following stages

a.   Initially the context data model is constructed to establish the project scope. A previously developed model may also be revised to reflect new requirements.

b.   A key-based data model is drawn that eliminates the non-specific relationships, adds associative entities and include the primary and the foreign keys.

c.    A fully attributed data model is constructed that includes all remaining attributes.

d.   Finally, the completed data model is analyzed for adaptability and flexibility through a process called normalization. The final analyzed model is known as a normalized data model.

3.   Data Modeling during Systems Design

During the system design process, the logical data model is transformed into a physical data model called the database schema. This model represents the technical capabilities and limitations of that database technology as well as the performance control for the database administrator.

4.   Automated Tools for Data Modeling

Data modeling can be performed by using the automated tools as well. Various tools like CASE and CAD can be used to store the information and the detailed descriptions of the data model. Most of the automated tools support the data modeling and the database design for a system development.

Using the automated tools, we can create professional data models without the use of templates and other conventional tools. The models can be easily modified and can be started over again. They also provide analytical tools to check for mechanical errors, completeness and consistency.

How to Construct Data Models

While constructing a data model, a previously existing data model should be properly analyzed. The existing model can be examined and may be used if possible. 

Otherwise a reverse engineering process may be applied to develop a new data model. If there doesn’t exist any data model, then we have to start the modeling process from the scratch. Some basic steps about data modeling are as follows.

1.   Entity Discovery

2.   Develop the context data model

3.   Develop the key-based data model

4.   Generalize the hierarchies

5.   Develop a fully attributed data model

Analyzing the Data Model

What is a good data model?

1.   A good data model is simple. The data attributes that describe any given entity should describe only that entity.

2.   A good data model is non-redundant.

3.   A good data model should be flexible and adaptable to future needs.

Data Analysis

Data analysis is a technique to improve a data model in preparation for the database designing process. It is a process that prepares a data model for implementation as a simple, non-redundant, flexible and adaptable database. 

This technique is also referred to as normalization.

Normalization is a data analysis technique that organizes data attributes such that they are grouped to form non-redundant, stable, flexible and adaptive entities. It is a three step technique that places a data model into first normal form(1NF), second normal form(2NF) and third normal form(3NF).

An entity is in first normal form (1NF) if there are no attributes that can have more than one value for a single entity. Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship.

An entity is in second normal form (2NF) if it is already in 1NF and the values of all non-primary key attributes are dependent on the primary key. Any attributes that are dependent to the primary key should be moved to a new entity. This may also need to create a new entity and relationship on the model.

An entity is in third normal form (3NF) if it is already in 2NF and if the values of its non-primary key attributes are not dependent on any other non-primary-key attributes. Any non-key attributes that are dependent on other non-key attributes must be moved or deleted. Again, new entities and relationship may have to be added to the data model.

Unit 8: Process Modeling

An introduction to Process Modeling

System Model plays a vital role in system development and system analyst has to deal with a variety of unstructured problems. The only solution to structure those problems is to create models. A model is a pictorial representation of the reality.

 Models can be built for existing systems to better understand them and also for a proposed system to document business requirement and technical designs.

Models can be of two types: logical and physical

Logical Models: it is a non-technical pictorial representation that depicts what a system is and what it does. The logical models illustrate the essence of the system. Logical models are also referred to as essential model, conceptual model and business model.

Physical Models: it is a technical pictorial representation that depicts what a system is and what it does and how the system is implemented. Physical models are also known as implementation or technical model.

In this regard, process modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes, logic, policies, and procedures. Initially process modeling is for the logical models and it focuses from the owners and user’s perspectives. Various tools like program structure charts, flowcharts, decision tables and DFDs are used in the process modeling.

DFDs

System Concepts for process modeling

External Agents

External agent is an outside person, organizational unit, a system or an organization that interacts with the system. Also known as an external entity, an external agent provides the inputs to the system and receive outputs from a system.

Data Stores

Process Concepts

Data Flows

The Process of Logical Process Modeling

1.   Strategic System Planning

Enterprise process modeling

2.   Process Modeling for Business Process Redesign

3.   Process Modeling during system analysis

-          Context data flow diagram

-          Functional decomposition diagram

-          Event response or use case list

-          Event handler

-          Event diagrams

-          System diagrams using event diagrams

-          Primitive diagrams for event processes that require additional processing details

4.   Process Modeling during system design

Transforming a logical process model into a physical model, called an application schema

5.   Fact finding and information gathering for process modeling

6.   Computer aided system engineering (CASE) for process modeling

How to construct Process Models

Once the data models are drawn, the following process models are built.

1.   The Context Data Flow Diagram

Also called, an environmental model or level 0 diagram, the context data flow diagram is a process model that is used to document the scope of the system. 

The scope defines what aspect of the business a system is supposed to support and how the system must interact with other systems and business as a whole. 

The system owners are directly concerned with the scope of the system from the communication point of view.  The scope of any project is always subjected to changes, so the context diagram is also subjected to constant changes.

The following strategy may be implemented to document the system’s scope

-          Think the system as a black box and distinguish the inside part from the outside. Ignore the working principle of the inner part. This is also referred to as black box thinking

-          Ask the users what business transaction a system must respond to. These are the inputs for the system and for each input, determine the source, and the source becomes the external agents for the context data flow diagram

-          Ask the users what sort of responses must be produced by the system. These are the outputs of the system and for each output, determine its destination and the destination also becomes the external agent.

-          Identify any other external data sources

-          Draw a context diagram from all the above information

2.   The functional decomposition diagram

The decomposition diagram shows the top-down functional decomposition or structure of a system. It also provides the foundation for drawing the data flow diagrams.

The functional decomposition diagram is drawn under following considerations

-          A root process is present that corresponds to the entire system

-          The system is divided into subsystems and functions that do not correspond to the organizational unit so as to build cross functional system that streamline processing and data sharing

-          The operational and reporting aspect of a system is also separated.

3.   The event response or use case list

After the decomposition diagram, we need to determine the business events that the system must respond. Generally there are three types of events

-          External events that are initiated by external agents. The input data flow occurs when the external event happens. For example, the external agent customer initiates an external event of order.

-          Temporal events that happen on the basis of time. When temporal event happen, an input control flow occurs. For example, the follow-up date of customer enquiry is a temporal event.

-          State events that occur on the basis of change in system from one state or condition to another. When a state event happens, the input control flow occurs. For example, the modification in a table of customer is a state event.

One of the most widely used approaches for finding and identifying events and responses is to utilize the use cases. With the use cases, we can identify and describe the necessary system processes from the perspective of the users.

4.   Event Decomposition Diagrams

To further divide the functions of the functional decomposition diagram, the event handling process is added to the decomposition. Separate pages may be added if the decomposition doesn’t fit on a single page, but a reference of the latter or the previous diagram should be provided. The event decomposition diagram serves as a good foundation for the future data flow diagrams

5.   Event diagrams

An event diagram is a context diagram for a single event. It shows the inputs, outputs and the data store interactions for a particular event. Before drawing an event diagram, we need to list out all the possible data stores and need to review the definition and attributes of each entity and data stores. For each event, we need to include the following:

-          The input and their sources. The data structure of each input should be recorded

-          The output and their destination. The data structure of each output should be recorded

-          Any data stores from which records must be read should be added to the event diagram. Data flow should also be added and named

-          Any data stores in which records must be created, deleted or updated should be included

6.   The system diagram

The system diagram is a collection of all the possible event diagrams and it shows all the events in the system or the subsystem.

7.   Primitive Diagrams

Some of the complex system diagrams may be exploded or decomposed into a primitive data flow diagram to see some more details. The primitive DFD shows the detailed processing requirements of the event. 

Unit 9: Feasibility Analysis and the System Proposal

Introduction

Feasibility Analysis is the process that measures how beneficial and practical an information system will be for an organization. Feasibility analysis of an information system must be conducted throughout the system development life cycle. 

The feasibility analysis is usually based on an extensive investigation and research of the system scope to give full comfort to the decision makers. The analysis aims at uncovering the potential weakness and threats of an existing or the proposed system as well as its strength and the opportunities.

Feasibility Analysis – A creeping commitment approach

The feasibility analysis of a system must be conducted throughout its life cycle. The creeping commitment approach is a strategy in which feasibility and the risks associated are continuously reevaluated throughout the project. In this approach, the project budgets and deadlines are adjusted according to the need of the project. 

The scope and complexity of a feasible project may change after the initial problems and opportunities are fully analyzed or after the system is designed. That is why, a project that is feasible at one point may become infeasible later.

The feasibility analysis may be done in the following phases of System Development Life Cycle

1.   System Analysis: Scope Definition Checkpoint

The first feasibility analysis is performed during the scope definition phase. In this stage, feasibility is a measure of the urgency of the problem and the estimate of the development costs. It answers whether the problems and the opportunities match the cost of detailed study and analysis of current system.

After estimating the benefits of solving the problems and opportunities, the estimate of development cost is conducted. The costs may be increased by 50 to 100 percent because most of the problems are not well defined and requirements are typically understated.

2.   System Analysis: Problem Analysis Checkpoint

After a more detailed study and problem analysis of the current system, the next checkpoint of feasibility study is conducting during the problem analysis.

3.   System Design: Decision Analysis Checkpoint

Six Test for Feasibility

1.   Operational Feasibility: is a measure of how well a solution meets the identified system requirements to solve the problems and take advantages of the opportunities of the system.

2.   Cultural and Political Feasibility: is a measure of how people feel about a solution and how well it will be accepted in a given organizational environment.

3.   Technical Feasibility: is the measure of a technical solution and the availability of the technical resources and expertise to implement and maintain it.

4.   Schedule Feasibility: is a measure of how reasonable the project timetable is

5.   Economic Feasibility: is a measure of the cost effectiveness of a project or the solution.

6.   Legal Feasibility: is a measure of how well a solution can be implemented within existing legal obligations. 

Cost Benefit Analysis Techniques

The economic feasibility is defined as the cost benefit analysis. It analyzes how the cost and benefits of a system can be estimated, and how they can be compared to determine the economic feasibility.

How much will the system cost?

The cost of a system can be divided into 2 categories

-          The cost of developing the system

-          The cost of operating the system

The development cost can be estimated from the viewpoint of the project and should be reviewed at the end of each phase of the project. 

The Operating cost can be estimated only after specific computer based solutions are defined.

The following list of development should be taken into considerations

1.   Personnel Costs: salaries and wages of analysts, programmers, consultants etc.

2.   Computer Usage Cost: A lot of time may be spent on programming, testing, conversion, word processing, prototyping etc. If the computer agency charges for the usage of computer, disk storage and printing, then the cost should also be estimated.

3.   Training costs: this is the cost incurred by the training of the staffs or the users of the system.

4.   Supply, duplication and equipment costs

5.   Cost of any new computer equipment and software

Some of the operating costs are:

1.   Fixed Costs: that occur at regular interval of time at relatively fixed rates. Examples include lease payment, house rents and software license payment.

2.   Variable Costs: that occur in proportion to some usage factor. Examples include cost of computer usage, supplies of forms, papers, disks and other overhead costs.

What benefits will the system provide?

1.   Tangible benefits: they are the benefits that can be easily quantified and measured in terms of monthly or annual savings or of profit to the organization.

 Some of the tangible benefits are

-          Fewer processing errors

-          Increased throughputs

-          Decreased response time

-          Elimination of job steps

-          Increased sales

-          Reduced credit losses

-          Reduced expenses

2.   Intangible benefits: they are the benefits that is believed to be difficult or impossible to quantify. They are the benefits that may be received by an organization not in physical terms but are in logical terms. Some of the intangible benefits are

-          Improved customer goodwill

-          Improved employee morale

-          Better service to community

-          Better decision making

Is the proposed system cost effective?

There are three popular techniques for assessing the cost effectiveness of a system.

-          pay-back analysis

-          return on investment

-          net present value

All three technique share one common concept, the time value of money. The time value of money concept states that a dollar today is worth more than a dollar after a year. 

The dollar today can be invested today and its interest combined may be more than the dollar after a year.

Payback Analysis: The payback analysis is a simple and popular technique for determining if and when an investment on a system will pay for itself. 

The system development costs are incurred initially and it will take some time for the benefits to overtake the costs. Even after the implementation, the operating costs are also added and that cost should also be paid back. 

Payback analysis determines how much time will be consumed before the benefits of the system overtake the costs. This period of time is also referred to as payback period.

The present value of a dollar in a year n depends on discount rate, which is a percentage similar to the interest on bank balances.

Return on Investment Analysis (ROI): The ROI technique compares the lifetime profitability of alternative solutions or the projects. 

It is a percentage rate that measures the relationship between the amount the business gets back for an investment and the amount invested. The lifetime ROI is calculated as follows

        Lifetime ROI = (Estimated Lifetime benefits – Estimated Lifetime costs)/Estimated Lifetime costs

Net Present Value (NPV): The net present value is an analysis technique that compares the annual discounted costs and benefits of alternative solutions. Initially the costs and benefits of the system for each year is determined and all the costs and benefits are adjusted back to the present values.

Feasibility Analysis of Candidate System

During the decision analysis phase, the system analyst identifies the candidate solutions and then analyzes those solutions for feasibility. A matrix format may be used to evaluate the candidate solutions.

1.   Candidate System Matrix

The candidate system matrix allows to compare the candidate systems on the basis of their characteristics. It documents the similarities and differences between the candidate systems. The columns represent the possible candidate solutions and the rows represent the characteristics of the candidates. Some of the characteristics that can be included are

-          Stakeholders

-          Knowledge

-          Processes

-          Communications

Various approaches may be used to identify the candidate solutions, like

-          Recognizing users’ ideas and opinions

-          Consulting methodology and architecture standards

-          Brainstorming possible solutions

-          Seeking references

-          Browsing appropriate journals and periodicals

	Candidate 1 Name	Candidate 2 Name	Candidate 3 Name
Stakeholders
Knowledge
Processes
Communications

Fig: sample candidate system matrix

2.   Feasibility Analysis Matrix

The feasibility analysis matrix is used to analyze and rank the candidate systems. The columns of the matrix includes the same candidate solutions and the rows include the feasibility criteria to describe the general solution and the ranking of the candidates.

	Weighting	Candidate 1	Candidate 2	Candidate 3
Description
Operational Feasibility
Cultural Feasibility
Technical Feasibility
Economic Feasibility
Schedule Feasibility
Legal Feasibility
Weighted score

The System Proposal

Once all the candidate solutions are identified and analyzed, the next stage is to select the best overall solution and recommend it to the management. Recommending a solution involves producing a system proposal. A system proposal is a report or presentation of a recommended solution. Some of the widely used system proposal concepts are written reports and presentation.

Written Report

It is a widely used method to communicate with the system users and it generates a large report that looks impressive. Following factors need to be considered while preparing the written reports

Length of the Written Report
                - To executive level managers – one to two page
                - To middle level managers – three to five pages
                - To supervisory level managers – less than 10 pages
                - To clerk level managers – less than 50 pages

Organization of the written report
Every report consist of both primary and secondary elements. Primary elements present the actual information that the report is intended to convey. Examples include introduction and conclusion. While secondary elements package the report so that readers can identify the actual primary elements. Some of the formats for written report are as follows

        Factual Format                                          Administrative Format
        - Introduction                                              - Introduction
        - Methods and procedures                             - Conclusions and recommendations
        - Facts and Details                                       - Summary and discussion of facts and details
        - Discussion and Analysis of facts and details            - Methods and procedures
        - Recommendations                                     - Final Conclusion
        - Conclusion                                                - Appendixes with facts and details

        Writing a report
        Some of the procedures while writing a report are
        - paragraphs should convey a single idea
        - sentences should not be too complex
        - write in an active voice
        - eliminate jargons, big words

Formal Presentation

-          Dress professionally

-          Avoid using the word I when making the presentation

-          Maintain eye contact with the group and keep an air of confidence

-          Be aware of your mannerism

-          Stop talking

-          Ask a question and let someone in the audience answer it

-          Try a little humor

Unit 10: System Design Methods

System design for in-house development – the “Build” solution

Tasks involved

1.   Design the Application Architecture

-          Application architecture is a specification of the technologies to be used to implement the information systems in terms of data, processes, interfaces, and network components

-          This task is accomplished by analyzing the data and process models created during requirement analysis

-          As decision on data, processes and interfaces are made, they are documented and the physical data flow diagram (PDFD) are also drawn.

-          The system analyst may employ system designers, system users, database administrators, network engineers, application administrators for this purpose

2.   Design the System Database

-          The next phase is to design the database specification

-          The designer must analyze how programs will access the data to improve the performance of the system.

-          The record size and the storage volume of the data should be considered as well

-          Designer should design the internal controls in the database to ensure security and disaster recovery techniques

-          The system analyst, system designers and the database administrators are employed in this phase

3.   Design the system Interface

4.   Package Design Specifications

5.   Update the project plan

-          Reevaluate the project feasibility and update the project plan

System Design for Integrating Commercial Software – The “Buy” Solution

Tasks involved

1.   Research Technical Criteria and Options

2.   Solicit Proposals or Quotes from vendors

3.   Validate vendor claims and performance

4.   Evaluate and rank vendor proposals

5.   Award contract and debrief vendors

Unit 11: Project Management

Introduction

A project is a temporary sequence of unique, complex and connected activities that have one goal or purpose and that must be completed within a specific time, within budget and according to the specification. Project management is the process of scoping, planning, staffing, organizing, directing and controlling the development of an acceptable system at the minimum cost and within a specified time.

Organization may take different approaches to project management. One approach is to appoint a project manager from the ranks of the team of an organization. Another approach believes that successful project managers apply a unique knowledge and skills that must be learned by other personnel. Organizations tend to hire and develop professional project managers who are assigned to one or more projects.

Process Management is an essential part for a successful project management. Process Management is the activity of documenting, managing and continually improving the process of systems development.

The Causes of Failed Projects

-          Failure to establish upper management commitment to the project

-          Lack of organization’s commitment to the system development methodology

-          Taking shortcuts through or around the system development methodology

-          Poor expectations management

o   Scope Creep: the unexpected or gradual growth of requirements during an information systems project

o   Feature Creep: the uncontrolled addition of technical features of a system

-          Premature commitment to a fixed budget and schedule

-          Poor estimating techniques

-          Over-optimism

-          Adding too many people to the team when the schedule gets behind

-          Inadequate people management skills

-          Failure to adapt business change

-          Insufficient resources

-          Failure to manage the plan

The Project Management Body of Knowledge

Project Manager Competencies

1.   Business Achievement Competencies

-          Business Awareness

-          Business partner orientation

-          Commitment to quality

2.   Problem Solving Competencies

-          Initiative

-          Information gathering

-          Analytical Thinking

-          Conceptual Thinking

3.   Influence Competencies

-          Interpersonal awareness

-          Organizational awareness

-          Anticipation of impact

4.   People Management Competencies

-          Motivating others

-          Communication skills

-          Developing others

-          Monitoring and controlling

5.   Self- Management Competencies

-          Self confidence

-          Stress management

-          Concern for credibility

-          Flexibility

Project Management Functions

1.   Scoping: defines the boundaries of the project. The project manager must project the expectations and the limitations in order to plan activities, estimate cost and manage expectations

2.   Planning: identifies the tasks required to complete the project. It is based on manager’s understanding of the scope and the methodology used to achieve the goal

3.   Estimating: estimate of time, people, skills of people, cost, resources, tools required for the project

4.   Scheduling: Schedule all project activities with respect to the project plan

5.   Organizing: The project manager should make sure that all other members of the project team understand their roles and responsibilities

6.   Directing: project manager should demonstrate people management skills to coordinate, delegate, motivate, advise, appraise and reward team members

7.   Controlling: The project manager must monitor the progress against the goals, schedule, costs and should make adjustments when needed

8.   Closing: A project manager should analyze the successes and failures of a project. They must learn from mistakes and should plan for continuous improvement of the system development process

Project Management Tools and Techniques

PERT

Project Evaluation and Review Technique (PERT) was developed in late 1950s to plan and control large weapons development for the US Navy. A PERT chart is a graphical network model used to depict the interdependencies between a project’s tasks. PERT is developed to make clear the interdependence between project tasks before those tasks are scheduled. The tasks are represented by boxes and an arrow indicates that one task is dependent on the start or completion of another task.

GANTT Chart

Gantt chart was developed by Henry L. Gantt in 1917 and it is the most commonly used tool for project scheduling and progress evaluation. A Gantt chart is a simple horizontal bar chart that depicts project tasks against a calendar. Each bar represents a named project task and the tasks are listed vertically in the left column. The horizontal axis represents the calendar time.

Gantt chart shows the overlapping tasks that can be performed at the same time. It also shows which tasks are ahead and which are behind the schedule. The Gantt chart is easy to learn, read, prepare and use.

The Project Management Life Cycle

The project management is a cross life-cycle activity that is project management activities overlap all the system development phases. The project management activities always match with the classic management functions like scoping, planning, estimating, scheduling, organizing, directing, controlling and closing.

The project management process combines the joint project planning (JPP) technique. Joint project planning is a strategy in which all stakeholders attend an intensive workshop aimed at reaching agreement on project decisions. The stakeholders include system owners, users, analysts, designers, and builders). The major project management activities in a project management cycle are listed below:

1.   Activity 1: Negotiate Scope

All the associated parties should agree to the project scope before any attempt is made to identify and schedule tasks or to assign resources to those tasks. Scope defines the expectations of a project and the boundaries of a project. The five basic questions answers the negotiation of the project scope

-          Product: what do you want?

-          Quality: how good do you want it to be?

-          Time: when do you want it?

-          Cost: How much are you willing to pay for it?

-          Resources: what resources are you willing or able to bring to the table?

2.   Activity 2: Identify Tasks

Once the project scope is known, the next step is to identify the major project tasks. Some phases of the tasks are too large and complex for planning, and scheduling. So we need to break down into activities and tasks until each task represents a manageable amount of work that can be planned, scheduled and assigned.

A work breakdown structure (WBS) may be implemented to identify and document project activities and tasks. A WBS is a graphical tool used to depict the hierarchical decomposition of a project into phases, activities and tasks.

3.   Activity 3: Estimate task durations

4.   Activity 4: Specify Intertask dependencies

5.   Activity 5: Assign Resources

6.   Activity 6: Direct the team effort

7.   Activity 7: Monitor and Control Progress

8.   Activity 8: Assess Project Results and Experiences