unit 2

• Enterprise software systems


  Software systems used in business organizations that have specific properties and requirements
• Enterprise software systems


  • Must support a wide range of functions
  • Part of a complex application landscape, connected to many other software systems via technical interfaces
  • Used by many users
  • Should work on as many devices as possible under different operating systems
  • Should be easily maintainable after it has been put into operation
  • Created by many people
  • Consist of many different components and subsystems
• Software is not tangible, but rather immaterial
• Defects in software cannot be seen, and you can never look directly at the components and their dependencies during the planning, construction, and use of software
• Neither the project manager nor the customer can get an idea of the actual "construction progress" of the software by inspecting a construction site
• Quality requirements for enterprise software systems

  • Functional suitability
  • Reliability
  • Fault tolerance
  • Usability
  • Performance efficiency
  • Maintainability
  • Portability
• Functional suitability


  Software should match its (intended) specification and do exactly what was stated in the specification
• Interoperability


  A software system is interoperable if it can be merged or integrated with other systems with little effort
• Reliability


  The software is available and the user can use it in the context of their business activities
• Fault tolerance


  If the software is not used as originally intended, or if a connected system does not behave as originally planned, the software system should behave tolerantly and not produce any uncontrolled errors or inconsistent data
• Usability


  Software is usable when users find it easy to use
• User experience


  Includes users' feelings when interacting with the software system
• Performance efficiency


  How the system complies with requirements such as response time and resource consumption
• Maintainability


  The ability of software to be changed in an economically viable way
• Reusability


  The probability with which a software system or parts of a system can be reused in a different context
• Portability


  The effort required to make software executable on a different platform compared to the (new) development effort for software
• Software engineering


  The structured and methodical planning, creation, and evolution of software systems, as well as their operation
• Smaller programs or apps for private use, or for highly specialized industrial applications, are sometimes created with little effort by one person
• Several dozen to a hundred people are often involved in implementing complex enterprise information systems over a period of several years
• Software engineering research is concerned with the evolution of existing methods and tools, as well as with the development and evaluation of new methods
• Typical risks of software projects

  • Project termination risks
  • Software applicability risks
  • Maintenance risks
• Project termination risks


  Requirements turn out to be unrealizable, costs go over budget, members have fundamentally different opinions or are at odds
• Software applicability risks


  Important business functions are missing or implemented incorrectly, quality requirements are not met, system is not accepted by users
• Maintenance risks


  Consequences of actions cannot be realized, internal structure has degenerated, no knowledge available about the technologies used in the legacy system
• Precise planning is usually not possible in software engineering projects
• The exact costs, the specific scope of functions, and the technical design of a software system can only be precisely determined at the end of a project
• Complex software projects are often started with an overarching business goal, but the specific functions, screen dialogs, and integration with other systems cannot be precisely specified at the beginning
• Relevant requirements are only recognized by users and customers after they have seen a first version of the system
• There is usually not just one stakeholder who makes requirements for the system, but multiple stakeholders with different and potentially conflicting requirements
• Software Engineering Process


  1. Planning

  2. Creation

  3. Evolution

  4. Operation
• Enterprise Software Systems


  • Immaterial
  • Require functional suitability, reliability, fault tolerance, usability, performance efficiency, maintainability, and portability
• Software Engineering


  Structured and methodical planning, creation, and evolution of software systems and their operation
• A core principle of software engineering is the division of the software project into various activities, the assignment of team members to responsibilities for certain activities, and the use of organizational and technical patterns that have proven themselves over several projects
• Complexity of enterprise software systems, immateriality of software, and expectations of client and user


  Lead to typical risks in software projects
• Software development is a highly (domain-)knowledge-driven process, and the requirements for the system in development can change in the course of a project
• Lack of business knowledge in the development team or lack of communication and coordination are typical causes of failed software projects
• Fundamental challenges in enterprise software engineering

  • Dealing with economic uncertainty
  • Dealing with technological uncertainty
  • Communication between those involved in the project
  • Dealing with conflicting goals
  • Technological complexity of enterprise software systems
• Attempts are often made to compensate for uncertainties by creating a plan that is as precise as possible, or a model that is as detailed as possible with all potential eventualities, which is called "analysis paralysis"
• The danger of "analysis paralysis" is that many resources are tied up, which are then missing when implementing an initial software version, and the analysis models that were elaborately created at the beginning often become obsolete due to newly gained knowledge during the implementation and presentation of the first software version