Fourth generation techniques (4GT)

Size: px
Start display at page:

Download "Fourth generation techniques (4GT)"

Transcription

1 Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some characteristic of software at a high level, the tool then automatically generates source code based on the developer s specification. The 4GT paradigm for software engineering focuses on the ability to specify software using specialized language forms or a graphic notation that describes the problem to be solved in terms that the customer can understand. Currently, a software development environment that supports the 4GT paradigm includes some or all of the following tools: Non-procedural languages for database query Report generation Data manipulation Screen interaction Definition & code generation; high-level graphics capability Spreadsheet capability Like other paradigms, 4GT begins with a requirements gathering step, the customer would describe requirements and these would be directly translated into an operational prototype. Advantages Simplified the programming process. Use non-procedural languages that encourage users and programmers to specify the results they want, while the computers determines the sequence of instruction that will accomplish those results. Use natural languages that impose no rigid grammatical rules. Disadvantages Less flexible that other languages Programs written in 4GLs are generally far less efficient during program execution that programs in high-level languages. Therefore, their use is limited to projects that do not call for such efficiency.

2 Questionnaires Questionnaires are a further method of information gathering where the potential users of the system are given questionnaires to be filled up and returned to the analyst. Questionnaires are special purpose documents that allow the analyst to collect information and opinions from respondents. Questionnaires are defined by Dibb Base document for research purposes, providing the question and structure for an interview or self completion and providing space for respondent s answers. Marshall said Questionnaires can help you collect information about what people do, what they have, what they think, know, feel or want. Using this technique we gather facts about the existing system from number of persons. Types of Questionnaires 1. Structured In structured questionnaires, respondent needs to select from possible options for answers and thus the range of answers is limited. Examples of structured questionnaires are- multiple choice, selection or ranking scale, selection of a rating and fill in the blanks. 2. Unstructured In such method, respondents are made to answer freely. Such questions are open ended. An open ended questionnaire just includes a question and has a sufficient space for an unstructured reply. Advantages Questionnaires are considered as an economical way of collecting facts from a huge number of people. If it is well formatted and designed, then the results can be easily analyzed and computerized. Respondents get time to think over the questions and provide more accurate data. Disadvantages Good questionnaires are difficult to construct.

3 Record review (recording outcome) Records and reports are the gathering of information and collected over the time by the users about the system and its operations. For better understanding of any existing system is to review its operations. For better understanding of any existing system is to reviewing of existing records or record review. It starts at the preliminary stage of the system study or later on in the study for measuring actual operations with what the records indicate. Records and reports may have a limitation if they are not up-to-date or if some essential links are missing. All the changes, which the system suffers, may not be recorded. Observations / site visit Another information gathering technique used by the system analyst is known as on site observation or direct observation, where the analyst personally goes to the site and discovers the functioning of the system. As an observer, the analyst can gain direct knowledge of the activities, operations, processes of the system on-site; hence here the role of an analyst is of an information seeker. This technique is useful when on needs to actually observe how documents are handled, how operations and activities are carried out. Advantages Facts gathered using this technique is highly reliable. Inexpensive way of collecting data. Using this technique, the system analyst can make out tasks that have been missing or wrongly illustrated by other fact finding techniques. Disadvantages This technique is too time-consuming and the analyst should not jump to conclusions or draw assumption from minute samples of observation rather the analyst should be more patient in gathering the information.

4 Joint application development (JAD) Joint application development (JAD) was developed by Chuck Morris of IBM Raleigh and Tony Crawford of IBM Toronto in the late 1970 s. in instance, JAD developed and gained general approval in the data processing industry. Originally, JAD was designed to bring system developers and users of varying backgrounds and opinions together in a productive and creative environment. The structured approach provides a good alternative to traditional serial interviews by system analysts. JAD is a technique that allows the developments, management, and customer groups to work jointly to build a product. It is a series of highly structured interviewed sessions aimed at reaching consensus on a project s goal and scope. A typical JAD project is from 3 to 6 months. JAD concept is based on 4 ideas The users who do the job have the best understanding of that job. Advantages Disadvantages The developers have the best understanding of how technology works. The business process and the software development process work the same basic way. The best software comes out of a process that all groups work as equals and as one. JAD actively involves users and management in the development project. JAD helps to avoid the requirements from being too specific and too vague, both of which cause trouble during implementation and acceptance. JAD reduces the amount of time required to develop systems since it eliminates process delays and misunderstandings and improves system quality. Slow communication and long feedback time. Weak or no support from upper management. Bad documentation.

5 FAST: Facilitated application specification technique ( FAST ) is an important technique for requirements elicitation. FAST is a technique for gathering requirements during early stages of analysis and specification. The main objective of this technique is to cover the gap between what the developers think they are going to design and what customers believe they will receive from the particular program. This is a team oriented approach for requirement gathering. Basic guidelines Meeting is conducted at a neutral site and attending by both software engineer and customer Rule for preparation and participation are established An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas A facilitator controls the meeting A definition mechanism is used The main goal is to identify the problem, purpose element of the solution, negotiate different approaches and specify a preliminary set of software requirements in an atmosphere that is conductive to accomplish the goal. Representatives of FAST Marketing person Software and hardware engineer Representative from manufacturing An outside facilitator

6 Software design concepts Following are software design or system design concepts: 1. Abstraction 2. Refinement 3. Modularity 4. Software architecture or structural design 5. Control hierarchy or program module 6. Data structures 7. Software procedures 8. Information hiding 1.Abstraction Abstraction let a designer to focus on solving a dilemma (problem) without being concerned about immaterial (irrelevant) lower level details. In other words, abstraction is closing the eyes (ignoring) to insignificant facts and focusing on key attributes. Abstraction is the act of representing essential features without including the background details or explanations. In the computer science and software engineering domain, the abstraction principle is used to reduce complexity and allow efficient design and implementation of complex software systems. Types of abstraction: 1] Procedural abstraction A procedural abstraction is a named sequence of instructions that has a precise (exact) and limited function. An example of a procedural abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc..) 2] Data abstraction A data abstraction is a named collection of data that describes a data object. In the framework of the procedural open noted above, we can identify a data abstraction called

7 door. For example, the data object door includes a set of characteristics (door type, door dimension) that depict the door object clearly. In this abstraction mechanism, representation and manipulation details are ignored. 3] control abstraction The third form of abstraction is the control abstraction. Like procedural and data abstraction, control abstraction implies a program control mechanism without specifying internal details. 2.Refinement It s the course of elaboration (explanation) where the designer provides consecutively (successively) more detail for each design component. Stepwise refinement is a top-down design strategy originally proposed by Niklaus wirth. A program is developed by successively refining levels of procedural detail. LEVEL 1- SYSTEM representing the overall product to be built. LEVEL 2 SUB-SYSTEMS representing the business processes associated with the system (one or more). LEVEL 3 PROCEDURES representing the work flow of each sub-system. There are essential two types of procedures; Administrative representing procedures executed by humans; and computer. LEVEL 4 PROGRAMS representing the programs needed to execute each computer procedure. Under stepwise refinement the levels are decomposed top-down during the design process, and implemented bottom-up; a common engineering/ manufacturing technique. 3. Modularity A module is a named entity that: Contains instructions, processing logic, and data structures. Can be separately compiled and stored in a library. Can be included in a program. Module segments can be used by invoking a name and some parameters. Modules can use other modules.

8 Modularity is the scale (degree) to which software can be understood by examining its components independently of one another. Modularity concept provides the advantages such as: To plan the growth of software in a more successful manner. Put up change easily. Conduct testing and debugging efficiently and proficiently. Conduct maintenance work without harmfully affecting the execution of the software. Myer defines five criteria that permit us to assess a design method with respect to its ability to define an effective modular system: Modular decomposability: if the design technique imparts an organized means for breaking problem into sub problems, it will decrease the complexity of the overall problem. Modular compos ability: if the design technique facilitates existing design components to be assembled into a new system, it will give up a modular solution that does not reinvent the wheel. Modular understandability: if a module can be understood as a standalone unit without reference to other module it will be easier to put up and easier to change. Modular continuity: if small changes to the system requirements consequence in changes to individual module, rather than system wide changes, the impact of change induced side effects will be minimized. Modular protection: if an unusual state crop up within a module and its effects are constrained within that module, then impact of error induced side effects are minimizes. 4. Software architecture (structural design) Software architecture also called structural design is a sketchy map of the system. In other terminology, structural design is the hierarchical construction of program modules, the mode in which these modules act together, and the structure of the data that are used by the modules.

9 The Goal of Architecture The purpose of architecture is to make out the requirements that influence the structure of the application. Expose the structure of the system but hide the implementation details. Realize all of the use cases and scenarios. Try to address the requirements of various stakeholders. Handle both functional and quality requirements. 5. Control hierarchy or program module Correspond to the module organization and implies a control hierarchy, but does not represent the procedural aspects of the software. The control relationship amongst modules is articulated in the following means: 1] A module that controls another module is said to be super ordinate to it and 2] A module controlled by another is said to be subordinate to the controlled. Structural partitioning Structural partitioning is achieved while following hierarchical nature in architectural design. The construction (structure) of a program can be partitioned into two ways: Horizontal partitioning Vertical partitioning

10 Function 1 Function 3 Function 2 Figure (a- Horizontal partitioning) Control module (Decision making modules) Worker modules Figure (b- Vertical partitioning)

11 In horizontal partitioning the control modules (as described in the shaded boxes in figure) are used to co-ordinate communication between and execution of the functions. Horizontal partitioning characterizes separate branches of the modular hierarchy for each major program function. Simplest way is to partition a system into: input, data transformation (processing), and output. Advantages Easy to test, maintain, and extend. Fewer side effects in change propagation or error propagation. Disadvantage More data to be passed across module interfaces. Make difficult the overall control of program flow. Vertical partitioning suggests the control and work should be distributed top-down in program structure. In vertical partitioning the control (decision making) modules are located at the top, and work is distributed top-down in the program structure. That is, top level modules perform control functions and do little actual processing, while modules that are low in the structure performs all input, computation and output tasks. Advantages Excellent at dealing with changes. Easy to sustain the changes. Lessen the change impact and propagation. 6. Data structure elements. It s the representation of the logical relationship among individual data 7. Software procedures The principles and procedures to be used to conduct design and development activities, including the following. The design and development processes to be pursue together with assignment of tasks, techniques to be used. Procedures for preparing unit test plans and conducting test.

12 8. Information hiding Information hiding is conceivably the most significant intellectual instrument developed to hold software design. Modules should be designed as well as specified in such an approach that information enclosed within one module is inaccessible to other modules that do not require such information. Effective Modular Design A module is a logically separable part of a program. It is a program unit that is discreet and identifiable with respect to compiling and loading. In terms of common programming language constructs, a module can be a macro, a function, a procedure (or subroutine), a process, or a package. In systems using functional abstraction, a module is usually a procedure of function or a collection of these. To produce modular designs, some criteria must be used to select modules so that the modules support well-defined abstractions and are solvable and modifiable separately. In a system using functional abstraction, coupling and cohesion are two modularization criteria, which are often used together. Function Independence The concept of functional independence is a direct outgrowth of modularity and the concepts of abstraction and information hiding. Functional independence is achieved by developing modules with single-minded function and an aversion to excessive interaction with other modules. Stated another way, we want to design software so that each module addresses a specific sub-function of requirements and has a simple interface, when viewed from other parts of the program structure. It is fair to ask, why independence is important. Software with effective modularity, that is, independent modules, is easier to develop because functions may be compartmentalized and interfaces are simplified (consider the ramifications when development is conducted by a team). Independent modules are easier to maintain (and test) because secondary effects caused by design or code modification are limited, error propagation is reduced, and reusable modules are possible. To summarize, functional independence is a key to good design, and design is the key to software quality. Cohesion Coupling

13

14

15

16

17

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

SYSTEM ANALYSIS CHAPTER 5. Expected Outcomes

SYSTEM ANALYSIS CHAPTER 5. Expected Outcomes CHAPTER 5 SYSTEM ANALYSIS Expected Outcomes To discuss requirements determination To study methods in gathering requirements To discuss the logical modeling of processes by referring to Data Flow Diagram

More information

Software Design. Design (I) Software Design Data Design. Relationships between the Analysis Model and the Design Model

Software Design. Design (I) Software Design Data Design. Relationships between the Analysis Model and the Design Model Software Design Design (I) Software Design is a process through which requirements are translated into a representation of software. Peter Lo CS213 Peter Lo 2005 1 CS213 Peter Lo 2005 2 Relationships between

More information

System Design Approaches. System Design. Model-Driven Approaches Modern Structured Design. Model-Driven Approaches

System Design Approaches. System Design. Model-Driven Approaches Modern Structured Design. Model-Driven Approaches System Design Systems design the specification of a detailed computer-based solution. Also called physical design. systems analysis emphasizes the business problem systems design emphasizes the technical

More information

1 INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN

1 INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN 1 INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN 1.1 INTRODUCTION Systems are created to solve problems. One can think of the systems approach as an organized way of dealing with a problem. In this dynamic

More information

Algorithms, Flowcharts & Program Design. ComPro

Algorithms, Flowcharts & Program Design. ComPro Algorithms, Flowcharts & Program Design ComPro Definition Algorithm: o sequence of steps to be performed in order to solve a problem by the computer. Flowchart: o graphical or symbolic representation of

More information

Introduction to Systems Analysis and Design

Introduction to Systems Analysis and Design Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.

More information

Objectives. Chapter 12. System Design. Model-Driven Approaches. System Design Approaches 2016-02-17. Systems Design

Objectives. Chapter 12. System Design. Model-Driven Approaches. System Design Approaches 2016-02-17. Systems Design McGraw-Hill/Irwin Chapter 12 Systems Design Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. 12-2 Objectives Describe the design phase in terms of your information building blocks.

More information

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers

More information

Functional Decomposition Top-Down Development

Functional Decomposition Top-Down Development Functional Decomposition Top-Down Development The top-down approach builds a system by stepwise refinement, starting with a definition of its abstract function. You start the process by expressing a topmost

More information

Chapter 8 Approaches to System Development

Chapter 8 Approaches to System Development Systems Analysis and Design in a Changing World, sixth edition 8-1 Chapter 8 Approaches to System Development Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases

More information

4. Multiagent Sys stems Design. Part 2: The PROMETHEUS methodology.

4. Multiagent Sys stems Design. Part 2: The PROMETHEUS methodology. 4. Multiagent Systems Design Part 2: Multiagent Syste ems (SMA-UPC) https://kemlg.upc.edu The PROMETHEUS methodology. Javier Vázquez-Salceda SMA-UPC Methodological Extensions to Object-Oriented Approaches

More information

Total Quality Management (TQM) Quality, Success and Failure. Total Quality Management (TQM) vs. Process Reengineering (BPR)

Total Quality Management (TQM) Quality, Success and Failure. Total Quality Management (TQM) vs. Process Reengineering (BPR) Total Quality Management (TQM) Quality, Success and Failure Total Quality Management (TQM) is a concept that makes quality control a responsibility to be shared by all people in an organization. M7011

More information

Quotes from Object-Oriented Software Construction

Quotes from Object-Oriented Software Construction Quotes from Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman. Chapter 10 Architectural Design

Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman. Chapter 10 Architectural Design Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman Chapter 10 Architectural Design 1 Why Architecture? The architecture is not the operational software. Rather, it is a representation

More information

Computer Science Department CS 470 Fall I

Computer Science Department CS 470 Fall I Computer Science Department CS 470 Fall I RAD: Rapid Application Development By Sheldon Liang CS 470 Handouts Rapid Application Development Pg 1 / 5 0. INTRODUCTION RAD: Rapid Application Development By

More information

Software Development Processes. Software Life-Cycle Models. Process Models in Other Fields. CIS 422/522 Spring 1998 1

Software Development Processes. Software Life-Cycle Models. Process Models in Other Fields. CIS 422/522 Spring 1998 1 1 Software Development Processes Sequential, Prototype-based RAD, Phased, Risk-based Spiral (c) 1998 M Young CIS 422/522 1/10/99 1 Software Life-Cycle Models Breaking projects down into pieces for... Planning

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements.

More information

Software Design Document (SDD) Template

Software Design Document (SDD) Template (SDD) Template Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase.

More information

Software Engineering. What is a system?

Software Engineering. What is a system? What is a system? Software Engineering Software Processes A purposeful collection of inter-related components working together to achieve some common objective. A system may include software, mechanical,

More information

OKLAHOMA SUBJECT AREA TESTS (OSAT )

OKLAHOMA SUBJECT AREA TESTS (OSAT ) CERTIFICATION EXAMINATIONS FOR OKLAHOMA EDUCATORS (CEOE ) OKLAHOMA SUBJECT AREA TESTS (OSAT ) FIELD 081: COMPUTER SCIENCE September 2008 Subarea Range of Competencies I. Computer Use in Educational Environments

More information

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e.

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e. Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e., a representation of information as a continuous flow that

More information

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development Fundamentals of Information Systems, Fifth Edition Chapter 8 Systems Development Principles and Learning Objectives Effective systems development requires a team effort of stakeholders, users, managers,

More information

Module 1. Introduction to Software Engineering. Version 2 CSE IIT, Kharagpur

Module 1. Introduction to Software Engineering. Version 2 CSE IIT, Kharagpur Module 1 Introduction to Software Engineering Lesson 2 Structured Programming Specific Instructional Objectives At the end of this lesson the student will be able to: Identify the important features of

More information

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group

More information

Background: Business Value of Enterprise Architecture TOGAF Architectures and the Business Services Architecture

Background: Business Value of Enterprise Architecture TOGAF Architectures and the Business Services Architecture Business Business Services Services and Enterprise and Enterprise This Workshop Two parts Background: Business Value of Enterprise TOGAF s and the Business Services We will use the key steps, methods and

More information

Ultimate Business Requirements

Ultimate Business Requirements Ultimate Business Requirements Writing Better and More Effective Business Requirements Training, Coaching, Consulting 1 Workshop Approach I hear, I know. I see, I remember. I do, I understand. Confucius

More information

A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS.

A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS. JASEM ISSN 1119-8362 All rights reserved Full-text Available Online at www.bioline.org.br/ja J. Appl. Sci. Environ. Manage. December, 2008 Vol. 12(4) 41-46 A Comparative Analysis of Structured and Object-Oriented

More information

UNIVERSITY OF SURREY. BSc Programmes in Computing. Level 1 Examination. CS183: Systems Analysis and Design. Time allowed: 2 hours Spring Semester 2006

UNIVERSITY OF SURREY. BSc Programmes in Computing. Level 1 Examination. CS183: Systems Analysis and Design. Time allowed: 2 hours Spring Semester 2006 CS/183/17/SS06 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2006 Answer ALL questions in Section A and TWO

More information

PHASE 2: SYSTEMS ANALYSIS. Steps in the Analysis Phase

PHASE 2: SYSTEMS ANALYSIS. Steps in the Analysis Phase Steps in the Analysis Phase Requirements Definition Requirements Analysis Techniques Requirements Gathering Techniques PHASE 2: SYSTEMS ANALYSIS System Requirements Steps in the Analysis Phase System analysis

More information

Object-oriented design methodologies

Object-oriented design methodologies Object-oriented design methodologies An object-oriented methodology is defined as the system of principles and procedures applied to object-oriented software development. Five years ago, there was no standard

More information

Software Development Processes. Software Life-Cycle Models

Software Development Processes. Software Life-Cycle Models 1 Software Development Processes Sequential, Prototype-based RAD, Phased, Risk-based Spiral (c) 1998 M Young CIS 422/522 4/3/98 1 Software Life-Cycle Models Breaking projects down into pieces for... Planning

More information

CHAPTER 11 REQUIREMENTS

CHAPTER 11 REQUIREMENTS Lecture Software Engineering CHAPTER 11 REQUIREMENTS Lecture Software Engineering Topics Determining What the Client Needs Overview of the Requirements Workflow Understanding the Domain The Business Model

More information

Objectives. Chapter 2: Operating-System Structures. Operating System Services (Cont.) Operating System Services. Operating System Services (Cont.

Objectives. Chapter 2: Operating-System Structures. Operating System Services (Cont.) Operating System Services. Operating System Services (Cont. Objectives To describe the services an operating system provides to users, processes, and other systems To discuss the various ways of structuring an operating system Chapter 2: Operating-System Structures

More information

Higher Computing. Software Development. LO1 Software Development process

Higher Computing. Software Development. LO1 Software Development process Software Development LO1 Software Development process Ian Simpson Inverurie Academy 2006 Software Development The candidate must demonstrate knowledge and understanding, practical skills and problem solving

More information

B. GENERATIONS OF PROGRAMMING LANGUAGES

B. GENERATIONS OF PROGRAMMING LANGUAGES LANGUAGE TRANSLATORS A. HIGH AND LOW LEVEL LANGUAGES Programming languages Low Level Languages Example: Assembly Language High-Level Languages Example: Pascal, Basic, Java Characteristics of LOW Level

More information

Architecture. Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/

Architecture. Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/ Architecture Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/ Some slides were adapted from L. Osterweil, B. Meyer, and P. Müller material Reda Bendraou LI386-S1

More information

UNIFACE Component-based. Development Methodology UNIFACE V7.2. 151157206-00 Revision 0 Dec 2000 UMET

UNIFACE Component-based. Development Methodology UNIFACE V7.2. 151157206-00 Revision 0 Dec 2000 UMET UNIFACE Component-based Development Methodology UNIFACE V7.2 151157206-00 Revision 0 Dec 2000 UMET UNIFACE Component-based Development Methodology Revision 0 Restricted Rights Notice This document and

More information

SOFTWARE REQUIREMENTS

SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities

More information

M 1: Management Overview. The Open Group. The Open Group Architecture Framework (TOGAF 9.1) Certification Level 1 and Level 2. Objectives.

M 1: Management Overview. The Open Group. The Open Group Architecture Framework (TOGAF 9.1) Certification Level 1 and Level 2. Objectives. M 1: Management Overview Agenda The Open Group The Open Group Architecture Framework (TOGAF 9.1) Certification Level 1 and Level 2 Architecture Forum Mission Stakeholders and Value What is an Enterprise?

More information

Chapter 2. Data Model. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel

Chapter 2. Data Model. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel Chapter 2 Data Model Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: Why data models are important About the basic data-modeling

More information

Software Development Life Cycle

Software Development Life Cycle 4 Software Development Life Cycle M MAJOR A J O R T TOPICSO P I C S Objectives... 52 Pre-Test Questions... 52 Introduction... 53 Software Development Life Cycle Model... 53 Waterfall Life Cycle Model...

More information

CUSTOMER-FOCUSED DEVELOPMENT WITH QFD

CUSTOMER-FOCUSED DEVELOPMENT WITH QFD Page 1 of 8 Quality function deployment (QFD) captures the voice of the customer (VOC), creates a product plan and deploys product requirements CUSTOMER-FOCUSED DEVELOPMENT WITH QFD Kenneth Crow DRM Associates

More information

Axiomatic design of software systems

Axiomatic design of software systems Axiomatic design of software systems N.P. Suh (1), S.H. Do Abstract Software is playing an increasingly important role in manufacturing. Many manufacturing firms have problems with software development.

More information

VALLIAMMAI ENGINEERING COLLEGE S.R.M. Nagar, Kattankulathur DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VALLIAMMAI ENGINEERING COLLEGE S.R.M. Nagar, Kattankulathur DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VALLIAMMAI ENGINEERING COLLEGE S.R.M. Nagar, Kattankulathur DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Sub Code : CP7007 Sub Name: SOFTWARE REQUIREMENTS ENGINEERING Branch / Year : ME CSE / I Year

More information

Object Oriented Design

Object Oriented Design Object Oriented Design Kenneth M. Anderson Lecture 20 CSCI 5828: Foundations of Software Engineering OO Design 1 Object-Oriented Design Traditional procedural systems separate data and procedures, and

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Foundations for Systems Development

Foundations for Systems Development Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and

More information

Process Models and Metrics

Process Models and Metrics Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers

More information

Overview of Programmable Logic Controllers (PLCs( PLCs) Dr. Fernando Rios-Gutierrez ECE4951- Design Workshop Spring 2007

Overview of Programmable Logic Controllers (PLCs( PLCs) Dr. Fernando Rios-Gutierrez ECE4951- Design Workshop Spring 2007 Overview of Programmable Logic Controllers (PLCs( PLCs) Dr. Fernando Rios-Gutierrez ECE4951- Design Workshop Spring 2007 Lecture Objectives Expose basic characteristics of PLC. Describe the various subparts

More information

Chapter 10 Developing Business/IT Solutions

Chapter 10 Developing Business/IT Solutions Chapter 10 Developing Business/IT Solutions 1. The systems approach to problem solving uses a systems orientation to define problems and opportunities and to develop solutions. When the systems approach

More information

Java: Learning to Program with Robots. Chapter 11: Building Quality Software

Java: Learning to Program with Robots. Chapter 11: Building Quality Software Java: Learning to Program with Robots Chapter 11: Building Quality Software Chapter Objectives After studying this chapter, you should be able to: Identify characteristics of quality software, both from

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34.

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34. Higher National Unit specification General information Unit code: HA4C 34 Superclass: CB Publication date: January 2016 Source: Scottish Qualifications Authority Version: 02 Unit purpose The purpose of

More information

CSE 5324: Software Engineering I (Analysis, Design, Creation)

CSE 5324: Software Engineering I (Analysis, Design, Creation) CSE 5324: Software Engineering I (Analysis, Design, Creation) Review Preview Brooks Book Chapter New stuff What is important What is next... Last class(es): Software Engineering is... Introduction, Terms,

More information

Better, Faster, and Cheaper SAS Software Lifecycle

Better, Faster, and Cheaper SAS Software Lifecycle Better, Faster, and Cheaper SAS Software Lifecycle Edmond Cheng, Bureau of Labor Statistics, Washington, DC ABSTRACT In designing software applications, the enduring process faces realistic business challenges

More information

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change?

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change? MANAGING THE DIGITAL FIRM, 12 TH EDITION Learning Objectives Chapter 13 BUILDING INFORMATION SYSTEMS VIDEO CASES Case 1: IBM: Business Process Management in a Service Oriented Architecture and Managing

More information

Umbrella: A New Component-Based Software Development Model

Umbrella: A New Component-Based Software Development Model 2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.

More information

IT Services Management Service Brief

IT Services Management Service Brief IT Services Management Service Brief Capacity Management Prepared by: Rick Leopoldi May 25, 2002 Copyright 2002. All rights reserved. Duplication of this document or extraction of content is strictly forbidden.

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Requirements and Duncker Diagrams

Requirements and Duncker Diagrams Requirements and Duncker Diagrams Table of Contents Reading...1 The Systems Engineering Method...2 Customer Expectations (Project Objectives and Mission Profile)...4 The Iterative Nature of the System

More information

Chapter 1 System Development Environment

Chapter 1 System Development Environment Chapter 1 System Development Environment Definition Information systems analysis and design: The organizational process to develop computer-based information systems. History In the early years of computing,

More information

Software Requirements Metrics

Software Requirements Metrics Software Requirements Metrics Fairly primitive and predictive power limited. Function Points Count number of inputs and output, user interactions, external interfaces, files used. Assess each for complexity

More information

Subject : System Analysis and Design BCA -II UNIT 1

Subject : System Analysis and Design BCA -II UNIT 1 Subject : System Analysis and Design BCA -II UNIT 1 Ques1 what is system design.explain its types. Ans: SYSTEM DESIGN :Systems design is the process or art of defining the architecture, components, modules,

More information

CHAPTER 2 PROBLEM SOLVING

CHAPTER 2 PROBLEM SOLVING CHAPTER 2 PROBLEM SOLVING This chapter will cover the following topics: Problem Solving Concepts for the Computer Pre-Programming Phase Programming Or Implementation Phase What Problem Can Be Solved By

More information

Chapter 7 Requirements Engineering. Software Engineering: A Practitioner s Approach, 6th edition by Roger S. Pressman

Chapter 7 Requirements Engineering. Software Engineering: A Practitioner s Approach, 6th edition by Roger S. Pressman Chapter 7 Requirements Engineering Software Engineering: A Practitioner s Approach, 6th edition by Roger S. Pressman 1 What is requirement engineering? Requirement engineering helps software engineers

More information

Business Process Modeling with Structured Scenarios

Business Process Modeling with Structured Scenarios Business Process Modeling with Structured Scenarios Doug Rosenberg ICONIX Software Engineering, Inc. In 2008, based on our experience with a number of business process engineering projects over the last

More information

The Role of the Software Architect

The Role of the Software Architect IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation

More information

Architectural Design

Architectural Design Software Engineering Architectural Design 1 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural

More information

Analyzing Software Architectures for Modifiability

Analyzing Software Architectures for Modifiability Analyzing Software Architectures for Modifiability PerOlof Bengtsson *, Nico Lassing **, Jan Bosch * and Hans van Vliet ** * Department of Software Engineering and Computer Science University of Karlskrona/Ronneby

More information

BCS HIGHER EDUCATION QUALIFICATIONS. BCS Level 5 Diploma in IT. Software Engineering 1. June 2015 EXAMINERS REPORT

BCS HIGHER EDUCATION QUALIFICATIONS. BCS Level 5 Diploma in IT. Software Engineering 1. June 2015 EXAMINERS REPORT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT Software Engineering 1 June 2015 EXAMINERS REPORT General Comments This is a technical paper about Software Engineering. Questions seek to

More information

Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP

Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP PROGRAMMING & SOFTWARE DEVELOPMENT AND INFORMATION SUPPORT & SERVICES PATHWAY SOFTWARE UNIT UNIT 5 Programming & and Support & s: (Unit 5) PAGE

More information

Software Engineering. Lecture 6 GSL Peru 2014

Software Engineering. Lecture 6 GSL Peru 2014 Software Engineering Lecture 6 GSL Peru 2014 Housekeeping Please turn in your High Level Product Specification No classes on holiday next Monday 28th and Tuesday 29th Friday s are not optional Video Crews

More information

Karunya University Dept. of Information Technology

Karunya University Dept. of Information Technology PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main

More information

Various Software Development Life Cycle Models

Various Software Development Life Cycle Models Various Software Development Life Cycle Models Sahil Jindal, Puneet Gulati, Praveen Rohilla Dronacharya College of Engineering, India Abstract:An SDLC model is a conceptual framework describing different

More information

Glossary of strategic planning terms

Glossary of strategic planning terms Glossary of strategic planning terms Action plan A detailed description of the strategies and steps used to implement a strategic plan. Baseline Base level of previous or current performance that can be

More information

RUP Design Workflow. Michael Fourman Cs2 Software Engineering

RUP Design Workflow. Michael Fourman Cs2 Software Engineering RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall

More information

Implementation of hybrid software architecture for Artificial Intelligence System

Implementation of hybrid software architecture for Artificial Intelligence System IJCSNS International Journal of Computer Science and Network Security, VOL.7 No.1, January 2007 35 Implementation of hybrid software architecture for Artificial Intelligence System B.Vinayagasundaram and

More information

Chapter 10 Structuring System Requirements: Conceptual Data Modeling. Copyright 2002 Prentice-Hall, Inc.

Chapter 10 Structuring System Requirements: Conceptual Data Modeling. Copyright 2002 Prentice-Hall, Inc. Chapter 10 Structuring System Requirements: Conceptual Data Modeling 10.1 Copyright 2002 Prentice-Hall, Inc. Learning Objectiveses 10.2 Define key data modeling terms Entity type Attribute Multivalued

More information

CC414- Lec 2. DataBase Models. Prof. Dr. Amani Saad. In this lecture, you will learn:

CC414- Lec 2. DataBase Models. Prof. Dr. Amani Saad. In this lecture, you will learn: CC414- Lec DataBase Models by Prof. Dr. Amani Saad 1 In this lecture, you will learn: Why data models are important About the basic data-modeling building blocks What business rules are and how they affect

More information

Software Engineering. So#ware Processes

Software Engineering. So#ware Processes Software Engineering So#ware Processes 1 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification defining

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

The MCSE Methodology. overview. the mcse design process. if a picture is worth a thousand words, an executable model is worth a thousand pictures

The MCSE Methodology. overview. the mcse design process. if a picture is worth a thousand words, an executable model is worth a thousand pictures The MCSE Methodology overview if a picture is worth a thousand words, an executable model is worth a thousand pictures The MCSE methodology the mcse methodology (méthodologie de conception des Systèmes

More information

Design with Reuse. Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1

Design with Reuse. Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Design with Reuse Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Objectives To explain the benefits of software reuse and some reuse

More information

Software Paradigms (Lesson 1) Introduction & Procedural Programming Paradigm

Software Paradigms (Lesson 1) Introduction & Procedural Programming Paradigm Software Paradigms (Lesson 1) Introduction & Procedural Programming Paradigm Table of Contents 1 Introduction... 2 1.1 Programming Paradigm... 2 1.2 Software Design Paradigm... 3 1.2.1 Design Patterns...

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

Manage Software Development in LabVIEW with Professional Tools

Manage Software Development in LabVIEW with Professional Tools Manage Software Development in LabVIEW with Professional Tools Introduction For many years, National Instruments LabVIEW software has been known as an easy-to-use development tool for building data acquisition

More information

Phase 2 Systems Analysis. Dr. Feng-Jen Yang

Phase 2 Systems Analysis. Dr. Feng-Jen Yang Phase 2 Systems Analysis Dr. Feng-Jen Yang Phase Description Systems analysis is the 2nd phase in the systems development life cycle (SDLC) Use requirements modeling, data and process modeling, and object

More information

SysML Modelling Language explained

SysML Modelling Language explained Date: 7 th October 2010 Author: Guillaume FINANCE, Objet Direct Analyst & Consultant UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 EXAMINERS REPORT Friday 2 nd October 2015 Answer any THREE

More information

The Elective Part of the NSS ICT Curriculum D. Software Development

The Elective Part of the NSS ICT Curriculum D. Software Development of the NSS ICT Curriculum D. Software Development Mr. CHEUNG Wah-sang / Mr. WONG Wing-hong, Robert Member of CDC HKEAA Committee on ICT (Senior Secondary) 1 D. Software Development The concepts / skills

More information

The V-Model. Prepared for. Prepared by. Christian Bucanac c.bucanac@computer.org Software Engineering Student, University Of Karlskrona/Ronneby

The V-Model. Prepared for. Prepared by. Christian Bucanac c.bucanac@computer.org Software Engineering Student, University Of Karlskrona/Ronneby Course: Quality Management, DPT404 Teacher: Conny Johansson Department: IDE, University Of Karlskrona/Ronneby The V-Model Prepared for Conny Johansson Conny.Johansson@ide.hk-r.se IDE, University Of Karlskrona/Ronneby

More information

Lecture 9: Requirements Modelling

Lecture 9: Requirements Modelling A little refresher: What are we modelling? Lecture 9: Requirements Modelling Requirements; Systems; Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview

More information

Business Analysis Lifecycle

Business Analysis Lifecycle Business Analysis Lifecycle by Sergey Korban Aotea Studios Ltd November 2011 Contents Introduction... 3 Business Analysis Lifecycle... 4 Practical Application... 5 Start-Up Phase... 5 Initiation Phase...

More information

CHAPTER 3 : METHODOLOGY

CHAPTER 3 : METHODOLOGY CHAPTER 3 : METHODOLOGY 3.0 INTRODUCTION This chapter describes the methods and the methodology that have been use to implement in this thesis. The primary data sources and data collected will describes

More information

Module 9. User Interface Design. Version 2 CSE IIT, Kharagpur

Module 9. User Interface Design. Version 2 CSE IIT, Kharagpur Module 9 User Interface Design Lesson 21 Types of User Interfaces Specific Instructional Objectives Classify user interfaces into three main types. What are the different ways in which menu items can be

More information

A Comparison of SOA Methodologies Analysis & Design Phases

A Comparison of SOA Methodologies Analysis & Design Phases 202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering

More information