Fall 2008
Assignment No. 4
Due Date:
Your assignment must be uploaded/submitted before or on 30th May, 2009.
Max Marks: 20
Uploading instructions:
Please view the Assignment Submission Process document provided to you by the
o The assignment should be in .doc format.
o Save your assignment with your ID (e.g. bx020200786.doc).
o The assignment submission through email is highly discouraged.
Rules for Marking:
It should be clear that your assignment will not get any credit if:
o The assignment is submitted after due date.
o The submitted assignment file is corrupted.
o The assignment is copied.
o The assignment material is directly copied from internet.
Note:
Your answer must follow the below given specifications. You will be assigned no marks if you do not follow these instructions.
· Font style: “Times New Roman”
· Font color: “Black”
· Font size: “12”
· Bold for heading only.
· Font in Italic is not allowed at all.
· No formatting or bullets are allowed to use.
Assignment Topic:
The topic of the assignment is System Analysis and Design Methodologies.
Objective:
We have learnt about System analysis and Design Methodologies in Lesson 23. The objective of this assignment is to prepare a student for a detailed study of different methods to evaluate different methods.
Assignment:
Evaluate and compare the following System analysis and design methodologies:
Ø Organisational Process Modelling (OPM)
Ø Soft Systems Methodology (SSM).
Ø Unified Modelling Language (UML
Ø Structured Systems Analysis and Design Method (SSADM)
___________________________________
Hints for SOLUTION
___________________________________
System Analysis
System analysis can be defined simply as: “The study of business problem domain to recommend improvements and specify the business requirements for the solution.”
The major components of system design are:
• Designing usable and complete input
• Designing well defined and usable output with flexibility to redefine presentation of outputs in any form.
• Designing file or database
• Designing user interface (input screen as it would be seen by the user)
Design Methodologies.
It involves determining scope and structure:
• Scope – Whether the database is local or global. If interdependence of organizational units is high, the data base has to be global in order to prevent sub-optimization of sub units. As it becomes global, the cost of maintenance enhances.
• Structure – refers to the ways data is stored in partitions and sequences. Various design methodologies can be used for devising a suitable structure in accordance with the needs of the organization and the new system.
Ø Organizational Process Modelling (OPM)
Where formal organizations are the setting in which decisions are made, the particular decisions or policies chosen by decision-makers can often be explained through reference to the organization's particular structure and procedural rules. Such explanations typically involve looking at the distribution of responsibilities among organizational sub-units, the activities of committees and ad hoc coordinating groups, meeting schedules, rules of order etc. The notion of fixed-in-advance standard operating procedures (SOPs) typically plays an important role in such explanations of individual decisions made.
BPM addresses the process aspects of business architecture, leading to all encompassing enterprise architecture. The relationships of a business processes in the context of the rest of the enterprise systems (e.g., data architecture, organizational structure, strategies, etc.) create greater capabilities when analyzing and planning enterprise changes. For example, during a corporate merger it is important to understand the processes of both companies in detail so that management can correctly and efficiently identify and eliminate redundancies in operations.
Business process modeling has always been a key aspect of business process reengineering (BPR) and continuous improvement approaches, such as Six Sigma. For routine business activities, BPM tools such as Provision, Intalio,
HISTORY
The classic business process modeling methodologies such as the flow chart, functional flow block diagram, data flow diagram, control flow diagram, Gantt chart, PERT diagram, and IDEF have emerged all over the 20th century: The Gantt chart around 1900, the flow charts in the 1920s, Functional Flow Block Diagram and PERT in the 1950s, Data Flow Diagrams and IDEF in the 1970s. IDEF0 is probably the most common technique of traditional business process modeling. These represent just a fraction of the methodologies used over the years to document business processes. Methods from the new millennium here are Unified Modeling Language and the Business Process Modeling Notation. The term "business process modeling" itself was coined in the 1960s in the field of systems engineering. S. Williams in 1967 published the article "Business Process Modeling Improves Administrative Control." His idea was that techniques for obtaining a better understanding of physical control systems could be used in a similar way for business processes. August Wilhelm-Scheer is regarded as founding the modern Business Process Modeling software industry with the development of the Y-model and the founding of IDS Scheer in the 1980s.
In the 1990s the term "process" became a new productivity paradigm. Companies were encouraged to think in "processes" instead of "functions" and "procedures". Process thinking looks horizontally through the company for inducing improvement and measurement.
Business process modeling became the base of new methodologies, that for example also supported data collection, data flow analysis, process flow diagrams and reporting facilities. Around 1995 the first visually oriented tool for business process modeling and implementation were being presented.
Business model
A business model is a framework for creating economic, social, and/or other forms of value. The term business model' is thus used for a broad range of informal and formal descriptions to represent core aspects of a business, including purpose, offerings, strategies, infrastructure, organizational structures, trading practices, and operational processes and policies.
Business process
A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. There are three main types of business processes:
- Management processes, the processes that govern the operation of a system. Typical management processes include "Corporate Governance" and "Strategic Management".
- Operational processes, processes that constitute the core business and create the primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.
- Supporting processes, which support the core processes. Examples include Accounting, Recruitment, and Technical support.
A workflow is a depiction of a sequence of operations, declared as work of a person, work of a simple or complex mechanism, work of a group of persons, work of an organization of staff, or machines. Workflow may be seen as any abstraction of real work, segregated in work share, work split or whatever types of ordering. For control purposes, workflow may be a view on real work under a chosen aspect.
Ø Soft Systems Methodology (SSM).
The sessions immediately before this have described the Snyder process. It is a detailed process which applies action research principles to the task of evaluating a program or unit. This session examines another detailed action research process, soft systems methodology.
Checkland has explained how it is intended to deal with complex situations while maintaining adequate standards of rigour. He also explicitly identifies it as an action research methodology.
In this session I begin by describing it as Checkland does. I then offer a different description, one which relates it to some of the concepts of action research discussed in earlier sessions.
SSM briefly
At the heart of SSM is a comparison between the world as it is, and some models of the world as it might be. Out of this comparison arise a better understanding of the world ("research"), and some ideas for improvement ("action").
The "ideal" models are then compared to the actual situation. Differences between the models and reality become the basis for planning changes.
The description above is mainly taken from recent literature. This and the earlier SSM literature also offer a 7-stage description, which follows. I use Checkland's terminology for the labels.
Note that this is necessarily a brief description -- you are referred to Checkland for more detail.
The 7-stage description
1 The problem situation unstructured
2 The problem situation expressed
3 Root definitions of relevant systems
4 Making and testing conceptual models
5 Comparing conceptual models with reality
6 Identify feasible and desirable changes
7 Action to improve the problem situation
A different description
This is the same process being described here. It is just that I'm taking a different perspective. You can think of soft systems methodology as progressing through four dialectics. It is in such terms that I describe it below.
I would draw your attention to a number of features of the process just described:
- It uses both a process, and the theoretical concepts known as systems thinking. You could substitute a different conceptual base -- a different set of concepts -- if you wished to.
For example, you could substitute different systems models, or even non-systems models.
- It contains multiple cycles within multiple cycles. Each cycle is in some sense a test of the researchers' conceptions of the situation. The implementation phase provides the final test.
- As described above, it says more about the research than about the action. All of the issues discussed in earlier sessions are relevant, especially those related to relationships and participation.
Soft systems methodology is also primarily used for problem solving, or for system improvement. The second of these uses implies that it can be used for process evaluation. And indeed it can.
Ø Unified Modelling Language (UML)
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering.
UML includes a set of graphical notation techniques to create abstract models of specific systems.
HISTORY
The Unified Modeling Language (UML) is an open method used to specify, visualize, construct and document the artifacts of an object-oriented software-intensive system under development. UML offers a standard way to write a system's blueprints, including conceptual components
UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 1.0 major revision
Modeling
It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — documentation such as written use cases that drive the model elements and diagrams.
UML diagrams represent two different views of a system model
- Static (or structural) view: Emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
- Dynamic (or behavioral) view: Emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
UML models can be exchanged among UML tools by using the XMI interchange format.
Structure diagrams
Structure diagrams emphasize what things must be in the system being modeled:
- Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
- Component diagram: depicts how a software system is split up into components and shows the dependencies among these components.
- Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
- Deployment diagram serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware.
- Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time.
- Package diagram: depicts how a system is split up into logical groupings by showing the dependencies among these groupings.
Since structure diagrams represent the structure of a system, they are used extensively in documenting the architecture of software systems.
Behavior diagrams
Behavior diagrams emphasize what must happen in the system being modeled:
- Activity diagram: represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
- State machine diagram: standardized notation to describe many systems, from computer programs to business processes.
- Use case diagram: shows the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
Interaction diagrams
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
- Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
- Interaction overview diagram: are a type of activity diagram in which the nodes represent interaction diagrams.
- Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespan of objects relative to those messages.
- Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.
The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.
Ø Structured Systems Analysis and Design Method (SSADM)
1. Structured Systems Analysis and Design Method (SSADM) is a systems approach to the analysis and design of information systems. SSADM was produced for the Central Computer and Telecommunications Agency (now Office of Government Commerce), a
Overview
SSADM is a waterfall method by which an Information System design can be arrived at. SSADM can be thought to represent a pinnacle of the rigorous document-led approach to system design, and contrasts with more contemporary Rapid Application Development methods such as DSDM.
SSADM is one particular implementation and builds on the work of different schools of structured analysis and development methods, such as Peter Checkland's Soft Systems Methodology, Larry Constantine's Structured Design, Edward Yourdon's Yourdon Structured Method, Michael A. Jackson's Jackson Structured Programming, and Tom DeMarco's Structured Analysis.
The names "Structured Systems Analysis and Design Method" and "SSADM" are now Registered Trade Marks of the Office of Government Commerce (OGC), which is an Office of the
SSADM Techniques
The 3 most important techniques that are used in SSADM are:
Logical Data Modeling
Data Flow Modeling
Entity Behavior Modeling
Stages
The SSADM method involves the application of a sequence of analysis, documentation and design tasks concerned with the following.
Analysis of the current system
Also known as: feasibility stage. Analyze the current situation at a high level. A Data Flow Diagram (DFD) is used to describe how the current system works and to visualize known problems. The following steps are part of this stage:
- Develop a Business Activity Model. A model of the business activity is built. Business events and business rules would also be investigated as an input to the specification of the new automated system.
- Investigate and define requirements. The objective of this step is to identify the problems associated with the current environment that are to be resolved by the new system. It also aims to identify the additional services to be provided by the new system and users of the new system.
- Investigate current processing. It investigates the information flow associated with the services currently provided, and describes them in the form of Data Flow Model. At this point, the Data Flow Model represents the current services with all their deficiencies. No attempt is made to incorporate required improvement, or new facilities.
- Investigate current data. This step is to identify and describe the structure of the system data, independently of the way the data are currently held and organised. It produces a model of data that supports the current services.
- Derive logical view of current services. The objective of this step is to develop a logical view of the current system that can be used to understand problems with the current system.
Detailed business specification
Also known as: requirements specification stage. To assist the management to make a sound choice, a number of business system options, each describing the scope and functionalities provided by a particular development/implementation approach, are prepared and presented to them. These options may be supported by technical documentation such as Work Practice Model, LDM (Logical Data Model) and DFD. They also require financial and risk assessments to be prepared, and need to be supported by outline implementation descriptions.
The following steps are part of this stage:
- Define required system processing. This step is to amend the requirements to reflect the selected Business System Option, to describe the required system in terms of system data flows and to define the user roles within the new system.
- Develop required data model. This step is undertaken in parallel with the above step. The LDM of the current environment is extended to support all the processing in the selected business system option.
- Derive system functions. During the parallel definition of data and processing, additional events are identified, which cause existing functions to be updated, and new functions to be defined. Service level requirements for each function are also identified in this step.
- Develop user job specifications. A Work Practice Model is developed to document the understanding of the user jobs in concern.
- Enhance required data model. Its objective is to improve the quality of the required system LDM by the application of relational data analysis (also known as normalization).
- Develop specification prototypes. It is used to describe selected parts of the required system in an animated form, for demonstration to the users. The purpose is to demonstrate that the requirements have been properly understood and to establish additional requirements concerning the style of the user interface.
- Develop processing specification. This step is principally concerned with defining the detailed update and enquiry processing for the required system.
- Confirm system objectives. During stage 1 and 3, the requirements will have been recorded, as they are identified, in the user requirements. This step represents the final review of the requirements before the completion of the Definition of Requirements Stage.
Logical data design
Also known as: logical system specification stage. In this stage, technically feasible options are chosen. The development/implementation environments are specified based on this choice. The following steps are part of this stage:
- Define BSOs (Business Systems Options). Its purpose is to identify and define the possible approaches to the physical implementation to meet the function definitions. It also validates the service level requirements for the proposed system in the light of the technical environment.
- Select BSO. This step is concerned with the presentation of the BSOs to users and the selection of the preferred option.
Logical process design
Also known as: logical system specification stage. In this stage, logical designs and processes are updated. Additionally, the dialogs are specified as well. The following steps are part of this stage:
- Define user dialogue. This step defines the structure of each dialogue required to support the on-line functions and identifies the navigation requirements, both within the dialogue and between dialogues.
- Define update processes. This is to complete the specification of the database updating required for each event and to define the error handling for each event.
- Define enquiry processes. This is to complete the specification of the database enquiry processing and to define the error handling for each enquiry.
Physical design
The objective of this stage is to specify the physical data and process design, using the language and features of the chosen physical environment and incorporating installation standards. The following activities are part of this stage:
- Prepare for physical design
- Learn the rules of the implementation environment
- Review the precise requirements for logical to physical mapping
- Plan the approach
- Complete the specification of functions
- Incrementally and repeatedly develop the data and process designs
SSADM (in common with other structured methodologies) adopts a prescriptive approach to information systems development in that it specifies in advance the modules, stages and tasks which have to be carried out, the deliverables to be produced and furthermore the techniques used to produce the deliverables. SSADM adopts the Waterfall model of systems development, where each phase has to be completed and signed off before subsequent phases can begin. SSADM is one example of a structured methodologies, a variety of others are widely used in ISE, including:
SSADM (Structured Systems Analysis and Design Methodology) is a methodology (Def. a system of ways of doing things especially regular and orderly procedures), used in the analysis and design stages of systems development. SSADM does not cover SITP issues or the construction, testing and implementation of software.
"SSADM has been used by the government in computing since its launch in 1981. It was commissioned by the CCTA (Central Computing and Telecommunications Agency) in a bid to standardize the many and varied IT projects being developed across government departments. The CCTA investigated a number of approaches before accepting a tender from Learmonth & Burchett Management Systems to develop a method." (Eva, SSADM Version 4 - A Users Guide)
Since 1981 SSADM has been further refined and version 4 was launched in 1990. SSADM is an open standard, i.e. it is freely available for use in industry and many companies offer support, training and Case tools for it.
0 comments:
Post a Comment