Topic 1 - Intro to ISE PDF

Topic 1 Introduction to Information Systems Engineering ISP550 INFORMATION SYSTEMS ENGINEERING 1  Learning Objectives Define Information Systems Engineering Define Information System Analysis and Design Describe the Systems D...

Topic 1 Introduction to Information Systems Engineering ISP550 INFORMATION SYSTEMS ENGINEERING 1  Learning Objectives Define Information Systems Engineering Define Information System Analysis and Design Describe the Systems Development Life Cycle (SDLC) Describe the System Development Methodologies such as agile methodologies, eXtreme Programming, Scrum, and RUP Describe the roles and responsibilities of participants in SDLC 2  Introduction Information systems support almost everything organizations do, whether the systems are developed for internal use, for exchanges with business partners, or for interactions with customers. Networks, especially the Internet are crucial for connecting organizations with their partners and their customers Information systems form the foundation for every major organizational activity and industry, from retail to healthcare to manufacturing to logistics. 3  Definition of Information System Information systems are computer-based infrastructures, organizations, personnel, and components that collect, process, store, transmit, display, disseminate, and act on information. ▪Information systems generally provide computer-based assistance to people engaging their environment as illustrated in Figure 1, where engagements and environments are often too complex and dynamic to be handled manually. 4  Definition of Information System (continue) Complex, dynamic engagements and environments require people to analyze and draw conclusions from an abstracted representation of the world, which enables them to make discrete decisions to achieve a desired effect in the world commensurate with their roles, tasks and capabilities. The abstraction is sometimes portrayed as a hierarchy (Figure 2) known as the Data, Information, Knowledge, and Wisdom (DIKW) paradigm. 5 Ackoff, R. L., “From Data to Wisdom,” J. Appl. Syst. Anal. 16, 3–9 (1989). Cleveland, H., “Information as Resource,” The Futurist, 34–39 (Dec 1982).  Definition of Information System (continue) Data Knowledge are the smallest symbolic units symbols are sufficiently abstract to enable that describe measured or people to make decisions about and interact estimated phenomena. with their environments. i.e.: sensors produce large combination of information with necessary volumes of data, but very little is data and judgment of historical patterns understood by humans. (experience). Information Wisdom information is a more abstract is knowledge combined with insights and understanding of the data common sense. derived by fusing data It is typically achieved by humans based on lowest layer where the symbolic knowledge, information, and data. units are interpretable by hard to derive automatically from lower-level humans. information representations. 6  TERM INFORMATION SYSTEMS ENGINEERING ▸ CONFERENCE ON ADVANCED INFORMATION INTERNATIONAL COUNCIL ON SYSTEMS SYSTEMS ENGINEERING (ISE COMMUNITY) ENGINEERING (INCOSE) Information systems engineering is situated at the intersection of information systems, ▸ Information Systems Engineering is an databases and software engineering. The term was interdisciplinary approach and means to enable coined around 1990, possibly in connection with the the realization of successful information systems. start-up of the later so successful CAiSE (Conference ▸ ISE focuses on defining customer needs and on Advanced Information Systems Engineering) required functionality early in the development series of conferences. cycle, documenting requirements, then proceeding with design synthesis, and system validation and deployment while considering the It is notable that there are indeed three research complete problem: - Operations & Maintenance, communities corresponding to each of the above- Performance, Cost & Schedule, Test, Realization, mentioned fields, the ISworld, DBworld and SEworld Training & Support, Disposal, Social aspects communities. 7 Information Systems Engineering: What Is It? (Wangler and Backlund, 2005)  TERM INFORMATION SYSTEMS ENGINEERING There are at least three broad areas of Information Systems Engineering integrates all knowledge that are needed for successful work in the disciplines and specialty groups into a team information systems engineering (cf. Iivari ): effort forming a structured development process knowledge of information systems domains that proceeds from concept to production to and applications, operation. knowledge about methods, models, and tools for business and systems analysis and design, Information Systems Engineering considers deployment, and operations and maintenance, both the business and the technical needs of all knowledge of the technology needed for customers with the goal of providing a quality building systems and integrating them with product that meets the user needs. legacy components. 8  Developing Information Systems and the Systems Development Life Cycle Systems development methodology A standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems The systems development life cycle (S D L C) The traditional methodology used to develop, maintain, and replace information systems Features several phases that mark the progress of the systems analysis and design efforts Notes: The systems development life cycle (SDLC) is a common methodology for systems development in many organizations; it features several phases that mark the progress of the systems analysis and design effort. Every textbook author and information systems development organization uses a slightly different life-cycle model 9  Systems Development Life Cycle The life cycle can be thought of as a circular process in which the end of the useful life of one system leads to the beginning of another project that will develop a new version or replace an existing system altogether (see Figure 3). At first glance, the life cycle appears to be a sequentially ordered set of phases, but it is not. The specific steps and their sequence are meant to be adapted as required for a project, consistent with management approaches. For example, in any given SDLC phase, the project can return to an earlier phase if necessary. Similarly, if a commercial product does not perform well just after its introduction, it may be temporarily removed from the market and improved before being reintroduced 10 Figure 3: Systems Development Life Cycle  Phases of the S D L C Planning Need for a new or enhanced system is identified Needs are identified, analyzed, prioritized, and arranged Determine the scope of the proposed system A baseline project plan is developed Analysis System requirements are studied from user input and structured Requires careful study of current systems, manual and computerized, that might be replaced or enhanced Output is a description of the alternate solution recommended by the analysis team 11  Phases of the S D L C Design The analyst converts the alternate solution into logical and physical specifications Logical Design The design process part that is independent of any specific hardware or software platform Physical Design The logical specifications of the system from logical design are transformed into technology- specific details from which all programming/system construction can be accomplished Choices of language, database, and platform are many times already decided by the organization or client 12  Phases of the S D L C Implementation Occurs when the information system is coded, tested, installed, and supported in the organization New systems become part of the daily activities of the organization Maintenance The phase in which an information system is systematically repaired and improved Organization’s needs may change over time requiring changes to the system based on user’s needs 13  Products of SDLC Phases Phase Products, Outputs, or Deliverables Planning Priorities for system and projects; an architecture for data, networks, and selection hardware, and information systems management are the result of associated systems Detailed steps, or work plan, for project Specification of system scope and planning and high-level system requirements or features Assignment of team members and other resources System justification or business case Analysis Description of the current system and where problems or opportunities exist, with a general recommendation on how to fix, enhance, or replace current system Explanation of alternative systems and justification for chosen alternative Design Functional, detailed specifications of system elements (data, processes, inputs, and outputs) Technical, detailed specifications of all system elements (programs, files, network, system software, etc.) Acquisition plan for new technology Implementation Code, documentation, training procedures, and support capabilities Maintenance New versions or releases of software with associated updates to documentation, 14 training, and support  15 Instead of systems requirements being produced in analysis, systems specifications being created in design and coding and testing being done at the beginning of implementation, current practice combines these activities into a single analysis–design–code–test process. These activities are the heart of systems development, as we suggest in Figure 1-7. This combination of activities is typical of current practices in agile methodologies. Figure 1-6: Systems Figure 1-7: Heart of Development Life Cycle Systems Development  General approaches to the SDLC Predictive Approach Waterfall model Assumes the project can be planned and that the information system can be developed according to the plan Requirements are well understood and/or low technical risk Adaptive Approach to the SDLC Agile /Iterative model Assumes the project must be more flexible and adapt to changing needs as the project progresses Requirements and needs are uncertain and/or high technical risk 16  The SDLC Traditional Waterfall Problems o Once one phase ends Figure 1-8: Traditional Waterfall SDLC another begins, going downhill until complete o Makes it difficult to go back o Results in great expense to make changes o Role of system users or customers narrowly defined o Focused on deadlines 17  Agile methodologies o Two well-known instances of agile methodologies are eXtreme Programming and Scrum, although there are other variations. o Agile methodologies share three key principles: 1. A focus on adaptive rather than predictive methodologies 2. A focus on people rather than roles 3. A focus on self-adaptive processes 18  The Agile Manifesto The agile methodologies group (The Seventeen Anarchists) argues that software development methodologies adapted from engineering generally do not fit with real-world software development. The Seventeen Anarchists uncover better ways of developing software by doing it and helping others do it. They have come to value 12 Agile Principles. --Kent Beck, Mike Beedle, Are van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jefferies, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas (www.AgileAlliance.org) 19  The Agile Manifesto 12 Agile Principle 1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. 4. Businesspeople and developers work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 20  The Agile Manifesto 12 Agile Principle 7. Working software is the primary measure of progress 8. Continuous attention to technical excellence and good design enhances agility. 9. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 21  Agile Methodologies—Not for Every Project Agile methodologies are not for everyone Fowler recommends an agile process if your project involves unpredictable or dynamic requirements responsible and motivated developers customers who understand the process and will get involved 22  Five Critical Factors that Distinguish Agile and 23 Traditional Approaches to System Development Factor Agile Methods Traditional Methods Size Well-matched to small products and teams Methods evolved to handle large products and Reliance on tacit knowledge limits scalability teams Hard to tailor down to small products Criticality Untested on safety-critical products Methods evolved to handle highly critical products Potential difficulties with simple design and lack Hard to tailor down to products that are not critical. of documentation Dynamism Simple design and continuous refactoring Detailed plans and Big Design Up Front, are are excellent for highly dynamic environments excellent for a highly stable environment but a but a source of potentially expensive rework for source of expensive rework for highly dynamic highly stable environments environments Personnel Requires continuous presence of a critical mass Needs a critical mass of scarce experts during of scarce experts. Risky to use non-agile people project definition but can work with fewer later in the project, unless the environment is highly dynamic Culture Thrives in a culture where people feel Thrives in a culture where people feel comfortable comfortable and empowered by having many and empowered by having their roles defined by degrees of freedom (thriving on chaos) clear practices and procedures (thriving on order)  Agile in Practice Three primary factors critical for success Delivery strategy: Continuous delivery of working software in short time scales Following agile software engineering practices Team capability: Agile principle of building projects around motivated individuals Agile development offers managers and programmers more choices in their efforts to produce good systems that come in on time and under budget 24  eXtreme Programming o Short, incremental development cycles o Focus on automated tests written by programmers o Emphasis on two-person programming teams o Customers to monitor the development process o Relevant parts of eXtreme Programming that relate to design specifications are 1. How planning, analysis, design, and construction are all fused into a single phase of activity 2. It’s unique way of capturing and presenting system requirements and design 25 specifications  eXtreme Programming oCoding and testing are related parts of the same process oAdvantages include Increased communications among developers Higher levels of productivity Higher quality code Reinforcement of other practices in eXtreme Programming Include code-and-test discipline 26  SCRUM Originated in 1995 by Sutherland and Schwaber Most popular methodology for agile (58%) Scrum framework includes Scrum teams with associated roles, events, artifacts, and rules Each team consists of three roles Product owner Development team Scrum master 27  SCRUM oScrum designed for speed and multiple functional product releases oPrimary unit is the Sprint (runs two weeks to a month) oStarts with an eight-hour Sprint planning meeting oWhat needs to be delivered by the end of the sprint oHow will the team accomplish that work oDaily Standup: A 15-minute meeting held to evaluate progress made within the past 24 hours and what needs to be done 28  At the end of the sprint, two additional SCRUM meetings The Sprint Review: (4 hours) focusing on the product, what has been accomplished, and what needs to be done The Sprint Retrospective: (3 hours) focusing on team performance and how it can improve Three primary artifacts in the Scrum process 1. Product Backlog: Listing of potential requirements 2. Sprint Backlog: Listing of only items to be addressed in a particular sprint 3. Increment: Represents the sum of all the Product Backlog items completed during a sprint. 29  Object-Oriented Analysis and Design (OOAD) oBased on objects rather than data or processes oCombines data and processes (called methods) into single entities call objects oObject: A structure that encapsulates attributes and methods that operate on those attributes oInheritance: Hierarchical arrangement of classes enabling subclasses to inherit properties of superclasses oObject Class: Logical grouping of objects that have the same attributes and behaviors 30  Relational Unified Process (RUP) o Relational Unified Process (RUP) is an object- oriented systems development methodology o Based on an iterative, incremental approach to systems development o RUPs four phases (each can be further divided) o Inception o Elaboration o Construction o Transition 31  Other Approach to System Development In recent years, several software development methodologies have emerged beyond Agile and Waterfall, reflecting the evolving needs of the industry. DevOps is more of a culture or a set of practices rather than a formal methodology. It emphasizes collaboration between development (Dev) and operations (Ops) teams to automate and streamline the software delivery process. Key Principles: Continuous Integration/Continuous Deployment (CI/CD) Infrastructure as Code (IaC) Monitoring and Logging Collaboration and Communication Benefits: Faster delivery of software, improved quality, reduced time to market, and more reliable releases. 32 33 Roles and Responsibilities of participants in SDLC Roles Responsibilities Project Manager Overseeing the entire project from inception to completion. (PM) Managing resources, timelines, and budgets. Ensuring that the project meets its objectives and is delivered on time. Coordinating communication between the team, stakeholders, and clients. Managing risks and issues that arise during the development process. Business Gathering and analyzing business requirements. Analyst (BA) Translating business needs into functional specifications. Acting as a liaison between stakeholders and the development team. Ensuring that the final product aligns with business goals. System Designing the overall system architecture. Architect Ensuring that the system meets the required performance, security, and scalability standards. Selecting the appropriate technologies and frameworks for development. Providing technical guidance to the development team. Development Writing code according to the specifications provided. Team Implementing the software design, including both the front-end and back-end. Conducting unit testing to ensure that individual components work as expected. Collaborating with other team members to integrate different modules. Quality Assurance Developing and executing test plans and cases. (QA) Team Performing various types of testing, such as functional, integration, system, and regression testing. Identifying, documenting, and tracking defects. 34 Ensuring that the software meets the required quality standards before release. Roles and Responsibilities of participants in SDLC Roles Responsibilities UI/UX Designer Designing the user interface and user experience for the software. Creating wireframes, mockups, and prototypes. Ensuring that the design is user-friendly and meets accessibility standards. Collaborating with developers to ensure the design is implemented correctly. DevOps Managing the deployment, automation, and maintenance of the development, testing, and Engineer production environments. Implementing Continuous Integration/Continuous Deployment (CI/CD) pipelines. Monitoring system performance and ensuring uptime. Managing infrastructure as code and ensuring security and compliance. Database Designing, implementing, and maintaining the database systems. Administrator Ensuring data integrity, security, and availability. (DBA) Optimizing database performance and performing regular backups. Collaborating with developers to integrate the database with the application. End Users Providing feedback during the design and testing phases. Participating in user acceptance testing (UAT) to ensure the product meets their needs. Using the final product and reporting any issues or enhancement requests. Stakeholders Providing input on the project’s requirements and objectives. Reviewing progress and making key decisions throughout the SDLC. Approving the final product before release. 35  Roles of an Information System Engineer An Information Systems Engineer (ISE) plays a crucial role in designing, developing, managing, and optimizing information systems that meet the needs of an organization. The role combines technical expertise with an understanding of business processes to ensure that technology solutions align with organizational goals ….not a job title, but a role that people play: 36  Summary In this chapter you learned how to: Define Information Systems Engineering Define Information System Analysis and Design Describe the Systems Development Life Cycle (SDLC) Describe the System Development Methodologies such as agile methodologies, eXtreme Programming, Scrum, and RUP Describe the roles and responsibilities of participants in SDLC 37