3.10: IT systems in organizations HL extension

This topic builds on the concepts introduced in “Introduction to project management” and providesstudents with a more in-depth understanding of the development of IT systems.

Information systems, people and teams• The role and need for IT in organizations• Organizational IT policies• IT personnel and organizational structure: for example, information system (IS) managers, supportstaff, network manager, database administrator• Development personnel: for example,, programmer, analyst, project manager

The people involved in IT systems can be grouped into two main categories:1. IT personnel and 2. Development personnel

1. IT personnelThe IT personnel are those that deal with policy issues related to IT systems and also day to day running of IT systems (both hardware and software). They include:

information system (IS) managers,o play a vital role in the implementation and administration of technology

within their organizations support staff

o Aid users in days to day running of their computers network managers

o are responsible for designing, implementing and administering computer network systems within an organisation or between organisations.

o Both the network and system administrators work below them.o Most of the time they deal with troubleshooting simple hardware and

software problems which users encounter in their daily usage of the computer

database administratoro Are responsible for the performance, integrity and security of a

database. Chief information officers (CIO)

o Are responsible for IT, IS and information strategy. They also align these to the needs of the business as a whole. They understand the impact of global digital economy and are usually part of organizations top management team. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.

2. Development personnelThe development personnel are those that deal the creation and deployment of IT systems in organization. They include:

programmers o they code and develop a system in a computer programming language

System analystso Specify the requirements for a system and the outline designs and

solutions that will meet the requirements. Typically the are the interface and liaison between the business users / analysts and the programmers

Business analysts

o Understand the complexity of the business and its needs and liaise with the system analyst. They are typically from the business side of the organization but adopt this role in the context of a particular development project for a specific period.

project managerso manage the project with particular emphasis on schedule and resources

The system development life cycle (SDLC)By the end of this topic, you should be able to explain what SDLC is with respect to:• Analysis of current situation• Organizational requirements• Methods of data collection: questionnaires, interviews, observation, literature searches• Feasibility study• Identification of possible IT solutions• Requirements specification• Justification of preferred IT solution• Project plan (who, why, what, when and how part of the project)• Project goals, scope and constraints, such as financial, time, technical, human-resource-related, risks,communication, procurement, quality• Project initiation document• Design considerations• Inputs, data structure, processes, outputs, user interface• Prototyping• Development of the IT solution• Initial testing, alpha testing• Quality assurance and quality control• Implementation• Training and support of staff, documentation to support the new IT system• Changeover methods: direct, phased and parallel running• Beta testing• Maintenance• Phase out

System Development

Complex projects will require a systems analyst. A systems analyst is an information specialist who performs systems analysis, design, and implementation.His or her job is to study the information and communications needs of an organization and determine what changes are required to deliver better information to people who need it, when they need it. Better information means information that is accurate, timely, and useful. The systems analyst achieves this goal through the problem solving method of systems analysis and design (SDLC).

The SDLC has an enormous influence as a general approach to develop information systems. Although there are many variants, it has the following basic structure:

1. Feasibility Study (also called Preliminary Investigation)2. System Analysis3. System Design4. System Development5. System Testing6. System Implementation7. System Evaluation & Maintenance

The systems development life cycle is better shown in diagrammatic form as in figure 1:

These stages are frequently referred to as “conventional system analysis”, “traditional system analysis”, “information systems development life cycle” or simply as “classical system development methodology”. SDLC is frequently called waterfall model in the USA. This classical systems development methodology varies (sometimes significantly) from a much more realistic and modern set of methods, which we collectively call agile development methods. We will review some of the agile methods later on in this topic. In the next few sections, we describe each stage in turn.

1. Feasibility Study (also called Preliminary Investigation)

Feasibility study looks at the present system, the requirements that it was intended to meet, problems in meeting these requirements, new requirements that have come to light since it was first implemented and briefly investigates alternative solutions. These must be within the terms of reference (TOR), given to the analyst relating to the boundaries of the systems and the constraints particularly those associated with resources. The possible solutions proposed as outcomes could be:

Leave the system as it is Improve the current system Completely replace the current system

For each of these three possible outcomes the following descriptions are given: Legal perspective Organization and social perspective Technical perspective Economic perceptive

In summary, the following is done this stage:a) Conduct preliminary analysis – includes stating objectives, defining nature and scope

of the problem.

Systems Design

SystemsDevelopment &

Testing

Systems Implementation

System Analysis

Feasibility Study

(Preliminary Investigation)

Systems Evaluation & Maintenance

FIGURE 1

b) Propose alternative solution- includes making decisions such as leaving the system alone, making it more efficient, or build a new system

c) Description of cost and benefits of each solution.d) Submit a preliminary plan with recommendations.

2. System Analysis

Analysis is used to get a clear idea of what the existing system does. With projects of any size, the analysis stage is essential because you can gain clear insight into data input, processing, and output without thinking about the computer system that may eventually be used.

This process is sometimes referred to (or sometimes taken to include) fact finding.  The classic fact-finding methods are:

   Conduct interviews

   Carry out questionnaires

   Study existing documents

   Search the literature for other solutions to the same problem.

  Observe people working with the existing system 

  Sample data taken from a carefully selected representation of the entire data source, if the data source is too large to be colleted

Studying existing documents will give details of the data collected while questionnaires can be used to gain general information from many people. Interviews will yield more detailed information (from fewer people or using more time). One can also observe the existing system and take into account the views of users of the existing system and users of the service the system provides (e.g. in a supermarket one would talk to customers as well as managers and check-out assistants).

A good analysis starts with a description of the problem  to be solved and an analysis of the data requirements.  A data flow diagram may usefully be used for this; the following symbols may appear (although there not complete consistency in practice): 

The box with rounded corners (maybe square or rectangular) which represents a process.

The box with an open right-hand side representing a data store.

The closed rectangle is a source or sink (destination) of data. It shows the limits of our diagram, how the data gets into or out of these boxes is not a concern of this diagram. 

These boxes are accompanied by arrows to show the direction of data flow. Often the arrows have other associated information such as the data that is on the move or, in other systems, the person responsible for the process.

We use Sandford Int’l school as an example: In our school, as in many others, a form tutor registers the students each morning and a list of absences from each class register is picked up by W/z Misrak (the headmaster’s secretary), so that she compile an “absence list” . This DFD is represented as diagram 2

No reference is made to hardware used, for example the registration may be fully automated or completed by hand. Students who attempt dataflow diagrams often try to do one or two of the whole system and this can lead to confusion. A better approach is to identify all the discrete uses of the system and diagram each one separately. For example, a fuller version of the registration system is:

1.  subject teacher takes register

2.   absent names noted by secretary

3.   absence list to office

4.   list produced

5.   late students to office

6.   removed late student from absence list

A common technique is to study the “actors” (people who use the system) to diagram how they use the system:

Registration System Secretary subject teacher Student

Diagram 2

  We can have a diagram called Use Case Diagram to represent a rough sketch of actual human interaction, as in diagram 3. The Use Case Diagram can then be followed by a description of the steps involved in each case of interaction between user and system.

                                          

Although the use of data flow diagrams and use case scenarios is not a requirement of student dossiers, we find that their use gives students valuable insight into real-world problems and help in the identification of system modules.

Summary of Phase Two – Analysis phaseIn this phase, the following steps are taken:

a) Gathering data using tools of written documents, interviews, questionnaires, observations, and sampling.

b) Analyze the data, using data flow diagrams, systems flowcharts, connectivity diagrams , grid charts and decision tables

c) Write a report.

The use of data flow diagrams and use case diagrams give students valuable insight into real-world problems and help in the identification of system modules when doing their internal assessment course work.

Summary of Phase Two – Analysis phaseIn this phase, the following steps are taken:

a) Gathering data using tools of written documents, interviews, questionnaires, observations, and sampling.

b) Analyze the data, using data flow diagrams, systems flowcharts, ERD, decision trees and decision tables

c) Write a report.

3. System DesignIn the third phase, (systems design), the analyst first does a preliminary design, next a detail design then writes a report.

a) Preliminary DesignThis describes the general functional capabilities of a proposed system. Usually several alternatives (candidates) are considered and the cost – benefit analysis done on each. Three tools may be used in this case:

i. Prototyping Tools: Prototyping refers to building a working model or experimental version of all or part of a system so that it can be quickly tested and evaluated. A prototype is a limited working system developed to test out design concepts. A prototype can also be said to be a mockup or developmental model of a system for test purposes. Prototyping tools are software packages that can be used to design screen displays.

ii. CASE Tools :CASE is Computer Aided Software Engineering. CASE Tools are software support tools that help in the information system development process.

Diagram 3

Examples are HyperAnalsyst, PacBase, Excelerator, Select Enterprise, Project 2000 and Application Development Workbench.

Project Management Software: This consists of programs used to plan, schedule and control the people, costs and resources required to complete a project on time. The software often uses Gantt and PERT charts.

A Gantt chart uses lines and bars to indicate the duration of a series of tasks. The time Scale may range from minutes to years. Gantt chart allows you to see weather tasks are being completed on schedule. (See previous notes on 3.9 Introduction to project management about how to construct Gantt charts)

iii. CPM (Critical Perth Method): This is whereby different ways (paths) to solving the project are considered. The path that represents the greatest time span is called the critical path.

A longer, detail explanation of what a critical path is follows: The difference between an activity’s earliest start date and its latest start date (or equally, the difference between its earliest and latest finish dates) is known as the activity’s float or slack. It is a measure of how much the start or completion of an activity maybe delayed without affecting the end date of the project. Any activity with a float of zero is critical in the sense that any delay in carrying out the activity, will delay the completion of the project as a whole. There will always at least one path through the network joining those critical activities; this is called the critical path. A PERT (Program Evaluation & Review Technique) chart shows not only timing but also relationships among the tasks of a project. The relationships are presented by lines that connect boxes describing the tasks. PERT is based on project network diagrams or charts with a particular feature for estimating the elapsed time of activities. PERT method is very similar to CPM technique (many books refer to them interchangeably); but instead of using a single estimate for the duration of each task as CPM, PERT requires three estimates:

Most likely time Optimistic time Pessimistic time

PERT coverage as a software development technique seems a bit advanced for an IB course like ITGS; it is mostly covered in later stages of undergraduate course.

I will provide two examples of CPM network diagrams, (which is like PERT but with only one estimation time) to gain a better understanding of how PERT and CPM are used in project risk analysis, scheduling and estimation:

EXAMPLES OF CPM CHARTS and how to use them

Example 1

Step 1: List the activitiesCPM analysis starts when you have a table showing each activity in your project. For each activity, you need to know which other activities must be done before it starts, and how long the activity takes.

Here's the example:

Activity Description Required Predecessor DurationA Product design (None) 5 months

B Market research (None) 1C Production analysis A 2D Product model A 3E Sales brochure A 2F Cost analysis C 3G Product testing D 4H Sales training B, E 2I Pricing H 1J Project report F, G, I 1

Step 2: Draw the diagramDraw by hand a network diagram of the project that shows which activities follow which other ones. This can be tricky. The analysis method we'll be using requires an "activity-on-arc" (AOA) diagram. An AOA diagram has numbered "nodes" that represent stages of project completion. You make up the nodes' numbers as you construct the diagram. You connect the nodes with arrows or "arcs" that represent the activities that are listed in the above table.

Some conventions about how to draw these diagrams:

All activities with no predecessor come off of node 1. All activities with no successor point to the last node, which has to have highest node

number.

In this example, A and B are the two activities that have no precedessor. They are represented as arrows leading away from node 1.

J is the one activity that has no successor, in this example. It therefore points to the last node, which is node 8. If there were more than one activity with successor, all of those activities' arrows point to the highest number node.

Students sometimes make the mistake of creating a diagram with several starting or ending nodes. Don't do this.

The trickiest part for me of building the above diagram was figuring what to do with activity H. I had drawn an arrow for activity B coming off node 1 and going to node 3. I had later drawn an arrow for activity E coming off node 2 and going to node 6. Since H requires both B

and E, I had to erase my first E arrow and redraw it so it pointed to the same node 3 that B did. H then comes off of node 3 and goes to node 6.

When designing these diagrams, work in pencil.

Example 1

A project consists of the following activities:

a) Draw an Activity-on-Arrow network diagram representing the project. (12) b) Calculate early and late start and finish times for each activity. (10)c) How much slack(float) does activity d have? Activity f ? Activity j ? (3) d) Which activities are critical? (4) e) If activity b were to take six days instead of three, how would the project finish date be affected? (3) f) Do any activities have free slack (float)? If so, which ones and how much?(3)

Example 2 Solution Example 2 (a) Solution

Example 2 (b) Solution

PATHS 1: A,B,D,H = 17 days 2: A,B,E,I = 16 days3: A,C,F,I = 20 days = Longest path = Critical path (no float) 4: A,C,G,J = 13 days

Example 2 (c) Solution

Example 2 (d) SolutionThe critical path is A,C,F,I. It is the longest path through the network (20 days) and all activities on the path, thus A, C, F and I, are critical activities.

Example 2 (e) SolutionActivity B has three days slack. Increasing the duration from 3 days to 6 days will use up the slack (float). Path A, B, D and H will increase to 20 days (originally 17 days) and will also become a critical path, together with path A,C,F,I.

Example 2 (f) SolutionFrom the table in Q 2b) it can be seen that five activities have slack or float, namely activities B, D, E, G, H and J where the duration of each are: B = 3; D = 3; E = 7; G = 7; H = 3; and J = 7.

b) Detail design: A detail design describes how the proposed information system will deliver the general capabilities described in the preliminary design. The following are usually considered output requirement, input requirements, storage requirement, processing requirement and systems control and backup.

Input Design

In this design the analyst considers the type of input devices to be used and how to validate and verify input data.In designing input records, the analyst usually considers the following controls or tests into the entry system:

i) Data verificationii) Data Validation

Verification means making sure that the data on the source documents is exactly the same as that input to the computer system.

Validation means attempting to make sure that the data input into the system makes sense.

 If it helps, remember that verification (ve) means making the data equal whereas validation (va) means checking if the data is acceptable. 

Verification

There are two main methods in common use:

Visual verification (or proof-reading) which means... (can you guess?) Double entry verification which involves having the data from the source document

entered twice as a check. Typically the application will lock the keyboard and give an audible warning so that the data entry person can check carefully.

One of these methods is more reliable than the other.  

Validation

Data entered into the computer can be unreasonable, a data entry person in a medical clinic can easily mistype a person’s weight, say or the number of cigarettes they smoke per day. This type of error is not caught by verification since the data may have been written down wrongly in the first place. 

Validation Methods:a) length checks: This assumes that the data has predetermined length. This normally involves string data types. If the number of characters do not match the valid number then this data is rendered invalid and rejected

b) type checks: Here the type of data entered is checked. This check ensures that numeric data is not entered in a name field or, conversely , alphabetic data into a numeric.

c) range checks: The assumption here is that there is an upper and lower limit of the target data (this normally involves currency values). Range check has the task of ensuring that out-of-range values are not permitted in as valid data.

d) Presence check: Normally when data is entered the analyst may have designed it to be entered with a special symbol at the end or beginning. The symbol may be a mark , a dot or just any special character. When data is being validated the presence of this symbol is an indication of valid data.

e) check digit test: A check digit is "a digit used for the purpose of performing a check".  However, if you give this answer in an exam you should not expect any marks. A check digit is a digit (single number) calculated from another number, added to that number and entered into the computer as a validation check. 

c) Write a report: this is a large detailed report. The report is normally accompanied with a presentation speech.

4. System Development and System Testing

This phase consists of acquiring hardware and software then testing the system.

Decision on hardware and software acquiring is of the form make-or-buy?There are two stages of testing:

a) Unit Testing: Here the individual parts of the program are tested using test (made up) data. Normally different sections (modules) are tested separately.

b) System Testing: Here the parts of the system are linked together and test data used to see if the parts work together. At this point actual firm’s data nay be used

There are other variants of testing, which usually refer to the specific type of test that needs to be performed on the system under development: they include, integration testing, acceptance testing, product testing, alpha testing and beta testing.

In the case of commercial of the shelf (COTS) software, as soon as product testing is complete, versions of the complete product are supplied to selected possible future clients for testing on site. The first such version is termed as alpha release and the testing done by these potential customers is called alpha testing. The corrected alpha release is called beta release; in general the beta release is intended to be close to the final version.

At the end of this long process, the organization will have a workable information system- one ready for implementation

5. System ImplementationThis consists of converting the hardware, software and files to the new system and of training the users. Conversion may proceed in four ways: direct, parallel, phased, or pilot.

a) Direct approach: means the user simply stops using the old system and starts using the new system.

b) Parallel approach: means the old and new systems are operated side by side until the new system has shown it is reliable, at which time the old system is discontinued.

c) Phased approach: means that parts of the new system are phased in separately.

d) Pilot approach: means that the entire system is tried out but only by some users.

In general the phased and pilot approaches are the most favorable. Phased is good for a large organization in which people are performing different tasks while pilot is good where people are performing the same task.

Training of users involves writing user manuals, video presentation and live classes – both one –on-one and group classes.

6. System Evaluation & Maintenance

This is the last phase and it deals with adjusting and improving the system through systems audit and periodic evaluation.Auditing means an independent review of an organization’s information system to see if all records and systems are as they should be. The analyst designs an audit trail. Audit trail is a designed system (method) that helps independent auditors trace the record of a transaction from its output back through all processing and storage to its source. Evaluation may be done by an accountant (through auditing), system analyst, user or the client (intended owner).

WATERFALL vs. AGILE METHODOLOGYhttp://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

By agilecollab

There is no IT meeting that does not talk and debate endlessly about Waterfall vs. Agile development methodologies.  Feelings run strong on the subject with many considering Agile ‘so of the moment’, just so right, while Waterfall is thought to be passé!  But, before deciding which is more appropriate, it is essentially important to provide a little background on both.

Waterfall

A classically linear and sequential approach to software design and systems development, each waterfall stage is assigned to a separate team to ensure greater project and deadline control, important for on-time project delivery.  A linear approach means a stage by stage approach for product building, e.g.

1.      The project team first analyses, then determining and prioritisingbusiness requirements / needs.

2.      Next, in the design phase business requirements are translated into IT solutions, and a decision taken about which underlying technology i.e. COBOL, Java or Visual Basic, etc. etc. is to be used.

3.      Once processes are defined and online layouts built, codeimplementation takes place.

4.      The next stage of data conversion evolves into a fully tested solution for implementation and testing for evaluation by the end-user.

5.      The last and final stage involves evaluation and maintenance, with the latter ensuring everything runs smoothly.

However, in case a glitch should result, changing the software is not only a practical impossibility, but means one has to go right back to the beginning and start developing new code, all over again.  That’s Waterfall for you! Now, as for minimal risk Agile, it is a low over-head method that emphasizes values and principles rather than processes.  Working in cycles i.e. a week, a month, etc., project priorities are re-evaluated and at the end of each cycle.  Four principles that constitute Agile methods are:

1.      The reigning supreme of individuals and interactions over processes and tools.

2.      As does, working software over comprehensive documentation.

3.      Likewise, customer collaboration over contract negotiation.

4.      And again, responding to change over plan follow-throughs.

To synopsise the difference between the two, one can say the classic waterfall method stands for predictability, while Agile methodology spells adaptability.  Agile methods are good at reducing overheads, such as, rationale, justification, documentation and meetings, keeping them as low as is possible.  And, that is why Agile methods benefit small teams with constantly changing requirements, rather more than larger projects.

Agile, based on empirical rather than defined methods (Waterfall) is all about light maneuverability and sufficiency for facilitating future development.  By defined methods what one means is that one plans first and then enforces these plans.  However, Agile methods involve planning what one wants and then adapting these plans to the results.  Extreme Programming (XP) is an excellent example of Agile methodology i.e.:

1.      Communication between customers and other team members;

2.      Simple, clean designs;

3.      Feedback given on Day 1 of software testing;

4.      Early delivery and implementation of suggested changes. 

Agile methodology means cutting down the big picture into puzzle size bits, fitting them together when the time is right e.g. design, coding and testing bits.  So, while there are reasons to support both the waterfall and agile methods, however, a closer look clarifies why many software and web design firms make the more appropriate choice of employing Agile methodology.  The following table enumerates the raison d’être for choosing Agile methodology over the Waterfall method.

1. Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs.  The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method.Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily.  With Agile, changes can be made if necessary without getting the entire programme rewritten.  This approach not only reduces overheads, it also helps in the upgrading of programmes.

2.  Another Agile method advantage is one has a launchable product at the end of each tested stage.  This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination.  This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.

3. Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications.  Whereas, there is only one main

release in the waterfall method and any problems or delays mean highly dissatisfied customers.

4. Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction.  As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage.  As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

 In conclusion, though on the plus side, waterfall’s defined stages allow for thorough planning, especially for logical design, implementation and deployment, Agile methodology is a sound choice for software development and web design projects.  More and more firms are becoming Agile!

What is PRINCE2? - PRINCE2 Definitionhttp://www.prince2.com/what-is-prince2.asp

PRINCE2 (PRojects IN Controlled Environments) is a process-based method for effective project management.

PRINCE2 is a de facto standard used extensively by the UK Government and is widely recognised and used in the private sector, both in the UK and internationally.

The method PRINCE2 is in the public domain, offering non-proprietorial best practice guidance onproject management. PRINCE2 is a registered trademark of OGC.

The key features of PRINCE2 are:

Its focus on business justification A defined organisation structure for the project management team Its product-based planning approach Its emphasis on dividing the project into manageable and controllable stages Its flexibility to be applied at a level appropriate to the project.

Introduction to Methodologies and SSADM

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

Introduction

In the early days of large scale information systems development many organisations used the Cobol programming language together with indexed sequential files to build systems for customer billing, payroll, stock control and a variety of other business areas. Developments at this time were characterised by :-

limited user involvement; inadequate requirements elicitation;

use of ad hoc analysis and design techniques; absence of CASE support for analysis and design; time consuming use of 3GL tools; inflexible file and 3rd generation database management systems.

Frequently the results of this approach were systems which, on delivery, did not satisfy business requirements. This caused extensive maintenance requirements and thus an increase in the applications backlog. A variety of problems may have caused the mis-match between system functionality and business requirements :-

a lack of ownership of and commitment to the system from users as a result of the low level of involvement;

business requirements may have changed between inception and delivery; requirements may have been mis-understood; inadequate analysis and design tools and techniques may have been used; or more likely a combination of these problems.

 The response from the information systems community to these problems was the development of structured methodologies for ISE. The purpose of these methodologies seems to have been to (a) formalise the requirements elicitation process to reduce the chances of mis-understanding the requirements and (b) to introduce best practice techniques to the analysis and design process

 SSADM (in common with other structured methodologies) adopts a precriptive 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 :

STRADIS: (Structured Analysis, Design and Implementation of Information Systems) a methodology developed by Gane and Sarson (1979). The methodology is based on the philosophy of top down functional decomposition and relies on the use of Data Flow Diagrams.

YSM: (Yourdon Systems Method,Yourdon, 1993). YSM is similar to STRADIS in its use of functional decomposition, however a middle-out approach is dopted and slightly more emphasis is placed on the importance of data structures.

MERISE: (Quang and Chartier-Kastler, 1991)The methodology is widely used in ISE in France, Spain and Switzerland. MERISE consists of three ‘cycles’, the decision cycle, the life cycle and the abstraction cycle. The abstraction cycle is the key, in this cycle both data and processes are viewed firstly at the conceptual level, then the logical or organisational level and finally at the physical or operational level.

EUROMETHOD: (CCTA, 1994) Euromethod could be described as a framework for the integration of existing european methodologies rather than as a methodology in its own right.

Contents Page

Home Page

 What is SSADM?

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 standardise 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.

Why is SSADM Used?

Within government departments SSADM has to be used. External contractors producing software for the government also have to use SSADM. SSADM is used by other companies because they expect the use of a disciplined ‘engineering approach will eventually improve the quality of the systems they produce. many companies have been willing to incur the considerable expense of implementing SSADM (e.g. staff training) with this expectation in mind.

Contents Page

Home Page

How is SSADM Controlled in the UK?

SSADM is managed by the CCTA, however the Design Authority Board (DAB) is responsible for maintaining and developing SSADM and the NCC (National Computing Centre) produce and maintain the definitive SSADM documentation.

Contents Page

Home Page

What are the Major Tools of SSADM?

SSADM revolves around the use of three key techniques, namely Logical Data Modelling, Data Flow Modelling and Entity/Event Modelling.

 Logical Data Modelling; This is the process of identifying, modelling and documenting the data requirements of a business information system. A Logical Data Model consists of a Logical Data Structure (LDS - The SSADM terminology for an Entity-Relationship Model) and the associated documentation. LDS s represent Entities (things about which a business needs to record information) andRelationships (necessary associations between entities). slide 7

 Data Flow Modelling; This is the process of identifying, modelling and documenting how data flows around a business information system. A Data Flow Model consists of a set of integrated Data Flow Diagrams supported by appropriate documentation. DFDs represent processes (activities which transform data from one form to another), data stores (holding areas for data), external entities (things which send data into a system or receive data from a system and finally data flows (routes by which data can flow). slide 8

 Entity Event Modelling; This is the process of identifying, modelling and documenting the business events which affect each entity and the sequence in which these events occur. An Entity/Event Model consists of a set of Entity Life Histories (one for each entity) and appropriate supporting documentation. slide 9

 Three Interdependent Views

The success of SSADM may lie in the fact that it does not rely on a single technique. Each of the three system models provides a different viewpoint of the same system, each of which are required to form a complete model of the system. Within SSADM each of the three techniques are cross reference against each other to ensure the completeness and accuracy of the complete model. slide 10

Contents Page

Home Page

 How is SSADM Structured?

SSADM consists of 5 main modules, which are in turn broken down into a complex hierarchy of stages, steps and tasks. slide 11

1. Feasibility Study; Module 1 the feasibility study consists of a single stage (Stage 0 Feasibility),which involves conducting a high level analysis of a business area to determine whether a system can cost effectively support the business requirements. In stage 0 an overview DFD is produced together with a high level LDS. At this stage the DFD will represent the existing

system warts and all and the LDS may be incomplete and contain unresolved M:M relationships. slide 12

2. Requirements Analysis; Module 2 requirements analysis consists of 2 stages; Stage 1 Investigation of Current Environment and Stage 2 Business System Options (BSO). During stage 1 the systems requirements are identified and the current business environment is modelled in terms of the processes carried out and the data structures involved. During stage 1 DFDs and an LDS are used to produce detailed logical models of the current system During stage 2 up to 6 business system options are produced and presented. As a result one of these options (or indeed a hybrid solution) is adopted and refined. During stage 2 DFDs and LDS are produced to support each business system option and the final chosen option. The transition from stage 1 to stage 2 is a key part of SSADM, this is where we move from a logical model of the current system to a logical model of the required system, i.e. this is where the DFDs and LDS have to be refined to cater new/changed requirements.slide 13

3. Requirements Specification; Module 3 Requirements Specification consists of a single stage (Stage 3 Definition of Requirements) which involves further developing the work carried out in module 2, detailed functional and non-functional requirements are identified and new techniques are introduced to define the required processing and data structures. In stage 3 the DFDs and LDS are refined and cross validated in the light of the chosen business system option. The LDS is enhanced using relational data analysis (normalisation). The DFDs and LDS are validated against the ELHs also produced during this stage. DFDs LDS and ELHs are used as input to the subsequent stages of SSADM. slide 14

4. Logical System Specification; Module 4 Logical System Specification consists of 2 stages; Stage 4 Technical System Options and Stage 5 Logical Design. In stage 4 up to 6 technical options (specifying the development and implementation environments) are produced, one being selected. In stage 5 the logical design of update and enquiry processing and system dialogues (menus etc.) is carried out.slide 15

5. Physical Design; Module 5 Physical Design consists of a single stage (Stage 6 Physical Design) in which the logical system specification and technical system specification are used to create a physical database design and a set of program specifications. slide 16

A more detailed description of the structure of SSADM appears in the recommended texts, e.g. SSADM Version 4 Models & Methods chapter 12 and SSADM Version 4 A Users Guide chapters 1 - 7. More detailed descriptions of the usage of the major tools will appear in the following chapters and are described in detail in the recommended texts, e.g. SSADM Version Models & Methods chapters 3, 4 and 7 and SSADM Version 4 A Users Guide chapters 8, 9 and 12.

Contents Page

Home Page

Tutorial Sheet: Introduction to SSADM

Objectives

The objective is to encourage you to view SSADM not as a magic pill which can be swallowed whole or not at all, but as an analysis & design framework or set of tools which can be adopted in whole or in part depending on requirements and which can be modified, tweaked or manipulated by people with sufficient experience and expertise.

Question 1

Of the three main tools of SSADM (LDS, DFD, ELH) which is the most important and why from the point of view of the analyst/designer? Which would be the easiest to understand from the end-users point of view?

Question 2

"When developing information systems the technical environment should be established as soon as possible to avoid any nasty surprises in the later stages of development." Is this a valid statement? If so why within SSADM do technical system options not get considered until the penultimate module.

Question 3

With so many possible implementation environments is there any point having a general physical design module?

Question 4

Why do you suppose ELHs are not used alongside the DFDs and LDS in the requirements analysis phase?

Question 5

Would SSADM be feasible without the support of CASE tools?

Overviewhttp://www.sei.cmu.edu/cmmi/ Carnegie Mellon Software Engineering Institute (SEI) ©2011 Carnegie Mellon University

CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes, which will improve their performance. CMMI-based process improvement includes identifying your organization’s process strengths and weaknesses and making process changes to turn weaknesses into strengths.CMMI applies to teams, work groups, projects, divisions, and entire organizations. Find out why CMMI     has been adopted by so many organizations worldwide. The published CMMI appraisal

results (PARS) searchable database of appraisal results lists hundreds of organizations that use CMMI.CMMI models are collections of best practices that help organizations to dramatically improve effectiveness, efficiency, and quality. These products, or CMMI solutions, consist of practices.Practices cover topics that include causal analysis; configuration management; quality assurance; verification and validation; risk management; requirements management; supplier management; project management; interface compatibility; make, buy, or reuse analysis; capacity management; availability management; disaster recovery, data collection, process performance; and more. View the inclusive set of CMMI process areas   to get a more complete picture of the topics it covers.To learn about CMMI and the People CMM, training on their use, and appraisal methods used to evaluate implementations, see CMMI Solutions.To learn about other improvement technologies that are designed to complement CMMI and the People CMM, visit CMMI Compatibility.CMMI is the result of over 20 years of ongoing work by the CMMI Product Team, which includes members from industry, government, and the SEI. The SEI ensures that the CMMI Product Suite continues to reflect effective practices.

Why CMMIWhy should you select CMMI for improving your business? There are multiple reasons.It leads to business success.Many CMMI using businesses have beneficial results to their bottom line. Some of these businesses have shared their success stories. There are many commonbenefits   that businesses have experienced, including improvements in schedule and cost performance, product and service quality, forecasting accuracy, productivity, customer satisfaction, return on investment, and other measures of performance.It is cost effective.All of these benefits are achieved with significant return on investment.It works well with other technologies.Businesses have learned through experience that CMMI Compatibility   exists with other technologies such as Agile, Scrum, Six Sigma, ITIL, ISO standards, Team Software Process, and Architecture-Centric Engineering.It has many users who share their experiences using CMMI.CMMI is used by small and large companies alike in a variety of industries including electronics, health services, finance, insurance, and transportation. User companies include Boeing, General Motors, JP Morgan, Bosch, and many others. Achievements of user organizations are available in company profiles, which include a summary of recent user activity (CMMI for SCAMPI Class A Appraisal Results - maturity profile) and the Published CMMI Appraisal Results (PARS) database of appraisal results. Many users share information inCommunity Discussions you can join.It has an excellent track record.The CMMI Timeline   shows that these products have a large following of users that have stayed with CMMI-based improvement since its inception in 1995.It is always improving.CMMI continues to evolve to meet the needs of businesses around the world. Significant consideration is given to insights and feedback received from the user community. Research   and development for future versions is ongoing.It has a solid reputation.CMMI work is centered at the Software Engineering Institute at Carnegie Mellon University. From its inception, CMMI has been committed to providing a product suite that is useful and usable, and that improves with time. The SEI works with process improvement experts from government and industry who are also CMMI users and support the maintenance of CMMI. Our people   are an important strength built into CMMI products.To find out which CMMI solutions   might be right for you, read Which CMMI Model Is for You? Although most businesses start with one model, others are benefiting from the use of multiple CMMI models. Ben Linders describes the benefits of using all three models in his post CMMI V1.3: Combining Acquisition, Development and Services.Getting started   with CMMI introduces the steps to improving your business performance.

Capability Maturity Model Integrationhttp://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

Capability Maturity Model Integration (CMMI) is a process improvementapproach whose goal is to

help organizations improve their performance. CMMI can be used to guide process improvement

across a project, a division, or an entire organization.

CMMI in software engineering and organizational development is a process improvement approach

that provides organizations with the essential elements for effective process improvement. CMMI is

registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally

separate organizational functions, set process improvement goals and priorities, provide guidance for

quality processes, and provide a point of reference for appraising current processes."[2]

Overview

CMMI currently addresses three areas of interest:

1. Product and service development — CMMI for Development (CMMI-DEV),

2. Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and

3. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

CMMI was developed by a group of experts from industry, government, and the Software Engineering

Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or

improving processes that meet the business goals of an organization. A CMMI model may also be

used as a framework for appraising the process maturity of the organization.[1]

CMMI originated in software engineering but has been highly generalised over the years to embrace

other areas of interest, such as the development of hardware products, the delivery of all kinds of

services, and the acquisition of products and services. The word "software" does not appear in

definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It

is not as specific to software engineering as its predecessor, the Software CMM (CMM, see below).

[edit]History

CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by

integrating many different models into one framework. The project consisted of members of industry,

government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors

included the Office of the Secretary of Defense (OSD) and theNational Defense Industrial Association.

CMMI is the successor of the capability maturity model (CMM) or Software CMM. The CMM was

developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released, Version 1.2 followed in

August 2006, and Version 1.3 in November 2010.

[edit]CMMI topics[edit]CMMI representation

CMMI exists in two representations: continuous and staged.[1] The continuous representation is

designed to allow the user to focus on the specific processes that are considered important for the

organization's immediate business objectives, or those to which the organization assigns a high

degree of risks. The staged representation is designed to provide a standard sequence of

improvements, and can serve as a basis for comparing the maturity of different projects and

organizations. The staged representation also provides for an easy migration from the SW-CMM to

CMMI.[1]

[edit]CMMI model frameworkFor more details on this topic, see Process area (CMMI).

Depending on the CMMI areas of interest (acquisition, services, development) used, the process

areas it contains will vary. Process areas are the areas that will be covered by the organization's processes. The table below lists the process areas that are present in all CMMI areas of interest. This collection of sixteen process areas is called the CMMI core process areas.

Capability Maturity Model Integration (CMMI) Core Process Areas

Abbreviation Name Area Maturity Level

CAR Causal Analysis and Resolution Support 5

Capability Maturity Model Integration (CMMI) Core Process Areas

Abbreviation Name Area Maturity Level

CM Configuration Management Support 2

DAR Decision Analysis and Resolution Support 3

IPM Integrated Project Management Project Management 3

MA Measurement and Analysis Support 2

OPD Organizational Process Definition Process Management 3

OPF Organizational Process Focus Process Management 3

OPM Organizational Performance Management Process Management 5

OPP Organizational Process Performance Process Management 4

OT Organizational Training Process Management 3

PMC Project Monitoring and Control Project Management 2

PP Project Planning Project Management 2

PPQA Process and Product Quality Assurance Support 2

QPM Quantitative Project Management Project Management 4

REQM Requirements Management Project Management 2

RSKM Risk Management Project Management 3

[edit]Maturity levels in CMMI for development

There are five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The

process areas below and their maturity levels are listed for the CMMI for Development model:

Maturity Level 2 - Managed

CM - Configuration Management

MA - Measurement and Analysis

PMC - Project Monitoring and Control

PP - Project Planning

PPQA - Process and Product Quality Assurance

REQM - Requirements Management

SAM - Supplier Agreement Management

Maturity Level 3 - Defined

DAR - Decision Analysis and Resolution

IPM - Integrated Project Management

OPD - Organizational Process Definition

OPF - Organizational Process Focus

OT - Organizational Training

PI - Product Integration

RD - Requirements Development.

RSKM - Risk Management.

TS - Technical Solution.

VAL - Validation.

VER - Verification.

Maturity Level 4 - Quantitatively Managed

OPP - Organizational Process Performance

QPM - Quantitative Project Management

Maturity Level 5 - Optimizing

CAR - Causal Analysis and Resolution

OPM - Organizational Performance Management

[edit]Maturity levels in CMMI for services

The process areas below and their maturity levels are listed for the CMMI for Services model:

Maturity Level 2 - Managed

CM - Configuration Management

MA - Measurement and Analysis

PPQA - Process and Product Quality Assurance

REQM - Requirements Management

SAM - Supplier Agreement Management

SD - Service Delivery

WMC - Work Monitoring and Control

WP - Work Planning

Maturity Level 3 - Defined

CAM - Capacity and Availability Management

DAR - Decision Analysis and Resolution

IRP - Incident Resolution and Prevention

IWM - Integrated Work Management

OPD - Organizational Process Definition

OPF - Organizational Process Focus

OT - Organizational Training

RSKM - Risk Management

SCON - Service Continuity

SSD - Service System Development

SST - Service System Transition

STSM - Strategic Service Management

Maturity Level 4 - Quantitatively Managed

OPP - Organizational Process Performance

QWM - Quantitative Work Management

Maturity Level 5 - Optimizing

CAR - Causal Analysis and Resolution

OPM - Organizational Performance Management

[edit]Maturity levels in CMMI for acquisition

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:

Maturity Level 2 - Managed

AM - Agreement Management

ARD - Acquisition Requirements Development

CM - Configuration Management

MA - Measurement and Analysis

PMC - Project Monitoring and Control

PP - Project Planning

PPQA - Process and Product Quality Assurance

REQM - Requirements Management

SSAD - Solicitation and Supplier Agreement Development

Maturity Level 3 - Defined

ATM - Acquisition Technical Management

AVAL - Acquisition Validation

AVER - Acquisition Verification

DAR - Decision Analysis and Resolution

IPM - Integrated Project Management

OPD - Organizational Process Definition

OPF - Organizational Process Focus

OT - Organizational Training

RSKM - Risk Management

Maturity Level 4 - Quantitatively Managed

OPP - Organizational Process Performance

QPM - Quantitative Project Management

Maturity Level 5 - Optimizing

CAR - Causal Analysis and Resolution

OPM - Organizational Performance Management

[edit]CMMI models

CMMI best practices are published in documents called models, each of which addresses a different

area of interest. The current release of CMMI, version 1.3, provides models for three areas of interest:

development, acquisition, and services.

CMMI for Development (CMMI-DEV), v1.3 was released in November 2010. It addresses

product and service development processes.

CMMI for Acquisition (CMMI-ACQ), v1.3 was released in November 2010. It addresses supply

chain management, acquisition, and outsourcing processes in government and industry.

CMMI for Services (CMMI-SVC), v1.3 was released in November 2010. It addresses guidance

for delivering services within an organization and to external customers.

Regardless of which model an organization chooses, CMMI best practices should be adapted by an

organization according to its business objectives.

[edit]Appraisal

An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the

type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level

achievement profile.

Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are

typically conducted for one or more of the following reasons:

1. To determine how well the organization’s processes compare to CMMI best practices, and to

identify areas where improvement can be made

2. To inform external customers and suppliers of how well the organization’s processes compare

to CMMI best practices

3. To meet the contractual requirements of one or more customers

Appraisals of organizations using a CMMI model[3] must conform to the requirements defined in the

Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals, A, B and

C, which focus on identifying improvement opportunities and comparing the organization’s processes

to CMMI best practices. Of these, class A appraisal is the most formal and is the only one that can

result in a level rating. Appraisal teams use a CMMI model and ARC-conformant appraisal method to

guide their evaluation of the organization and their reporting of conclusions. The appraisal results can

then be used (e.g., by a process group) to plan improvements for the organization.

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method

that meets all of the ARC requirements.[4] Results of an SCAMPI appraisal may be published (if the

appraised organization approves) on the CMMI Web site of the SEI: Published SCAMPI Appraisal

Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software

Process Improvement and Capability Determination), assessments etc.

[edit]Achieving CMMI compliance

The traditional approach that organizations often adopt to achieve compliance with CMMI models

involves the establishment of an Engineering Process Group (EPG) and Process Action Teams

(PATs)[5] This approach requires that members of the EPG and PATs be trained in the CMMI, that an

informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement.

More modern approaches that involve the deployment of commercially available, CMMI-compliant

processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on

the "time to move up" for organizations adopting the earlier Software CMM as well as CMMI. [6] These

statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months,

and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the

CMMI.

The Software Engineering Institute’s (SEI) Team Software Process methodology and the use of CMMI

models can be used to raise the maturity level. A new product called Accelerated Improvement

Method (AIM) combines the use of CMMI and the TSP.

[edit]Applications

The SEI published that 60 organizations measured increases of performance in the categories of cost,

schedule, productivity, quality and customer satisfaction.[7] The median increase in performance varied

between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals

with what processes should be implemented, and not so much with how they can be implemented.

These results do not guarantee that applying CMMI will increase performance in every organization. A

small company with few resources may be less likely to benefit from CMMI; this view is supported by

the process maturity profile (page 10). Of the small organizations (<25 employees), 70.5% are

assessed at level 2: Managed, while 52.8% of the organizations with 1001–2000 employees are rated

at the highest level (5: Optimizing).

Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences

between CMMI and agile methods, both approaches have much in common. They believe neither way

is the 'right' way to develop software, but that there are phases in a project where one of the two is

better suited. They suggest one should combine the different fragments of the methods into a new

hybrid method. Sutherland et al. (2007) assert that a combination of Scrum and CMMI brings more

adaptability and predictability than either one alone. David J. Anderson (2005) gives hints on how to

interpret CMMI in an agile manner. Other viewpoints about using CMMI and Agile development are

available on the SEI website.

The combination of the project management technique earned value management (EVM) with CMMI

has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming

(XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002).

For example, the XP requirements management approach, which relies on oral communication, was

evaluated as not compliant with CMMI.

CMMI can be appraised using two different approaches: staged and continuous. The staged approach

yields appraisal results as one of five maturity levels. The continuous approach yields one of

six capability levels. The differences in these approaches are felt only in the appraisal; the best

practices are equivalent and result in equivalent process improvement results.