Nur auf Docsity: Lade Enterprise Software Systems: Properties, Risks, and Challenges und mehr Mitschriften als PDF für Softwaretechnik / Software Engineering (SE) herunter!
UNIT 1 – STRUCTURE AND ORGANIZATION OF INFORMATION SYSTEMS
WHAT I NEED TO KNOW
- explain what it means to encode information using binary code
- name the units that make up a Von Neumann computer
- identify the typical elements in distributed systems
- name the elements of communication networks
- understand the types of enterprise information systems 1.1 0 AND 1 AS THE BASIS OF ALL IT SYSTEMS Digital systems store and process information in binary form, which means in the form of sequences of 0 and 1. One bit corresponds to the amount of information in an answer to a question with only two possibilities, but of course there can be more than two possible answers to a question, so we need bit sequences to store amounts of information that are greater than one bit. examples of real word applications of binary form:
- light switch that turns on and off
- flashlight that turns on and off
- optical storage media, like CDs, DVDs and Blu-Ray discs that have a spiral track made up of small peaks and valleys. Every change (increase or decrease) means 1 and every non-change means 0
- magnetic storage media such as hard drives, they store data on disks and are divided into many small areas: these areas can be set to one of two possible magnetic states, one state is spoken as “one” and the other as “zero”. All data stored and all programs executed on a computer system, manifest themselves as sequences of 0 and 1. BOOLEAN OPERATIONS The foundation of processing sequences of 0 and 1 were laid in the 19th century by George Boole. The term Boolean algebra describes an algebraic structure with the two elements (0 and 1) and the logical operations (AND, NOT, OR). The functionality of these operations can be implemented easily with electrotechnical assemblies and combined to form complex circuits. Boolean operation AND:
- two-digit operation;
- two boolean values (X and Y)
- if both values are equal to 1 then their value is 1;
- if one of them is not equal to 1, then their value is 0; Boolean operation OR:
- two-digit operation;
- two boolean values (X and Y);
- if at least one of the values is equal to 1 then their value is 1;
- if both of them are not equal to 1 then their value is 0; Boolean operation NOT:
- has only one input digit;
- it negates the value X to the other
- the value 1 is evaluated as 0, and 0 as 1;
STORING NUMBERS AND LETTERS
Computer systems can also calculate ordinary numbers and store and display letters and other characters. There are defined mappings and standards for this (for ex. ASCII or UTF-8). To perform mathematical calculations, the numbers are first converted into the binary system in which they get calculated and then transferred back to the decimal system. The conversion is necessary because computer systems can only calculate with 0 and 1. 1.2 VON NEUMANN ARCHITECTURE The basic functionality of all current computer systems was introduced in 1945 by John Von Neumann. He developed the idea of storing the computer programs in a shared memory (the main memory) of the computer, together with the data being processed.This made re-programming computers possible, because the instructions for processing data could be easily changed. Almost every common computer system produced today follows the Von Neumann Architecture.
TYPICAL ELEMENTS IN DISTRIBUTED SYSTEMS
A distributed system consists of a server, a client, a communication network and an agreement on the structure of the messages to be sent. server - they are computers that make functions (also called services) accessible to other computers via a communication network. example:
- search engine servers enable information to be found on the internet
- weather service servers provide information on the current weather situation
- online retailers servers offer search functions in the inventory client - they are the computers that use the services offered by the servers. example - a network printer is a server that offers the printing services for the local network, every computer that prints out a document via this printer is a client. Both roles only relate to the offering and requesting of services, and not to the required hardware of the devices. Most systems within an enterprise network act as a server as well as a client, depending on the service considered. Example - the customer relationship manager(CRM) system acts as a server, providing customer address data to the enterprise resource planning (ERP) system which then becomes the client. On the other hand the ERP also acts as a server to the CRM system, providing daily turnovers of every customer. communication network - it connects clients and servers and it consists of:
- physical components for data transmission (wires, antennas)
- technical components for routing and transferring data (routers, switches..)
- network interfaces to connect a device to a communication network (ethernet interface card, bluetooth chip) network interface - it enables a computer to communicate with other computers. In addition to physical connection (cable socket, built-in radio chip), it requires support from the operating system (software).
The components for data transmission ensure that information is transferred physically over a certain distance. The components of the data exchanged ensure that the data are transported in a communication network using the optimal route from sender to recipient. message - computers exchange information using messages. the structure and content of the message are application-specific and usually defined by the server. A message is defined as logically related information that is sent by an application. the network interface of a computer must transform the message into a bit sequence, which is then split for transmission into smaller data packets with a predetermined length. Example – a typical data packet transmitted through the internet via a digital subscriber line (DSL) connection can transport 1452 bytes of user data; to send an image file with a size off 500 kilobytes from one computer to another , at least 353 data packets must be generated and sent over the communication network. CONCEPTUAL MODELS FOR COMMUNICATION The messages must be transformed into data packets before they leave a computer, this transformation takes place in several steps and the type of message and communication determine what happens in these steps. The internet protocol suite (TCP/IP) and the open systems interconnection (OSI) reference model describe network architectures that encode the messages in a cascade of different layers in packets that are suitable for the transmission channel. They also decode received packets to combine them into a message. *the OSI model has never been implemented fully in practice yet The functions used for coding and decoding in a layer are called protocol and each layer is responsible for a very specific aspect of the message exchange between computers. OSI reference model (7 layers)
- application layer
- presentation layer
- session layer
- transport layer
- network layer
- data link layer
- physical layer TCP/IP reference model (4 layers):
- application layer
- transport layer
- internet layer
- link layer Application layer - the functions (protocols) of the application layer in both reference models contain application specific definitions of the structure and exchange of messages. Example – HTTP for calling up and transferring websites Presentation and session layer - elements of the presentation layer in the OSI model contain the definition of syntax and semantics of the information to be transmitted. They are responsible for tasks like character encoding, data compression, and encryption and decryption of information. The session layer enables sessions to be set up between remote computers, with one session the actions of bot computers can be controlled and synchronized in a targeted manner, which enables smooth interaction.
1.4 ENTERPRISE INFORMATION SYSTEMS
The term “enterprise information systems” is used to refer to a commercially used software systems and their system context. Almost every medium and large organization depends on the use of information systems to achieve its goals, some of them depend on IT support. (ex. Banks). We distinguish 4 different kinds of information systems:
- communication systems : they support interpersonal communication using email, video telephone, chat or social network (ex. Outlook)
- cross-sectional systems : all systems that are not communication systems but are also used as standard software (ex. Word, Excel)
- functional area information systems – they specifically support business processes and activities in organizations. There can be FAIS industry - neutral applications (ex. accounting systems), industry- specific solutions (ex. Banks, insurance companies) or individually developed solutions (when no common systems fits the organizational needs). The focus of FAIS systems is on the business processes.
- management information systems – they are used to support planning and decision-making processes. (ex. Data warehouse and business intelligence solutions). The focus is on data that are collected when the business processes are processed. Cleaned and compressed data from the FAIS are stored in these systems. These data can be summarized in the systems and prepared for the respective target group.
UNIT 2 – RISKS AND CHALLENGES OF ENTERPRISE SOFTWARE ENGINEERING
WHAT I NEED TO KNOW
- identify the typical properties of enterprise software systems
- understand the typical risks and problems that arise when carrying out software developments projects
- explain the causes of those risks and problems
- identify which challenges of enterprise software projects can be derived from typical problems and causes 2.1 PROPERTIES OF ENTERPRISE SOFTWARE SYSTEMS An enterprise software system:
- must support a wide range of functions
- is part of a complex application landscape, and is connected to many other software systems via technical interfaces
- is 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
- is created by many people
- consists of many different components and subsystems Software is immaterial. A completed software system manifests itself as a very long series of 0 and 1on a storage medium. It-s a challenge in many ways: defects cannot be seen and you can never work directly at the components and their dependencies during the planning, construction and use of software. You can’t get an idea of the actual construction progress of the software by inspecting a construction site.
QUALITY REQUIREMENTS THAT AN ENTERPRISE SOFTWARE SYSTEM SHALL FULFILL
Functional suitability – software should match its intended specification (it is supposed to do exactly what was stated in the specification). One important aspect of functional suitability is interoperability (a software is interoperable if it can be merged easily with other systems). Reliability – the software is available and the user can use it in the context of their business activities. It is relevant depending on how critical the application of the software is and the height of the potential damage due to failure. Fault tolerance – a 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), it often determines the success or failure of systems. Performance efficiency – how the system complies with requirements such as response time and resource consumption (typically in distributed systems where large number of users work at the same time). Maintainability – the ability of software to be changed in an economically viable way, it depends heavily on the internal structure of the software and its documentation. Maintainability decreases with increasing service life so it makes more sense to replace it with a new one. An important aspect is reusability, it describes the probability of a software or parts of it to be reused in a different context. Portability – it results from the effort required to make software executable on a different platform compared to the new development effort for software. It is relevant for applications that are intended for the end user and therefore must work on as many devices and operating systems as possible. 2.2 SOFTWARE ENGINEERING The term software engineering describes the structured and methodical planning, creation and evolution of software system, as well as their operation. It is defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. It Is a young discipline: each day software systems become more complex and powerful. Software systems are immaterial so their size and diversity are not limited by natural or physical law, there are almost no natural restrictions (gravity, friction, resistance). The power of software systems is strongly limited by the ability to develop abstract, logical structures as well as the communication abilities of people involved in the sof6ware project. Many recognized principles and methods of software engineering are therefore based on experience and knowledge in the development of complex information systems. A core principle of software engineering is the division of the software project int different activities and the distribution of members of the software team into distinct roles, another core principle is the use of patterns, the use of organizational structures that have proven themselves in several projects. Software engineering research is concerned with the evolution of existing methods and tools, as well as with the development and evaluation of new methods. 2.3 RISKS AND TYPICAL PROBLEMS The complexity of the system, with the immateriality of the system and expectations of the client and user leads to a number of typical risks.
Another typical cause of failed projects is the lack of communication and coordination among its participants. In development projects there are different departments involved, each with its own ideas and objectives. 2.5 CHALLENGES IN SOFTWARE ENGINEERING ECONOMIC UNCERTAINTY The earlier the total costs are estimated in a project, the higher the deviation from the actual effort at the end of the project. As the process progresses, an estimate of the total costs becomes more precise, but it is only at the end of the project that it is possible to determine the level of effort. TECHNOLOGICAL UNCERTAINTY A technological vision can be created at the beginning but the actual technical solution can only be precisely determined at the end of a project. At the beginning of a project, there is still a lot of freedom to decide which technologies to use. Technical decisions are made by the software architect. Since requirements are only recognized in the course of a project , the interim results must be checked continuously. Th e technical solution can then be adapted and expanded. As a rule, the possible scope for decision-making with regard to the technical solution becomes smaller as the project progresses, until a concrete solution has been worked out.
COMMUNICATION
The inclusion of various stakeholders represents an important challenge for enterprise software projects. New findings and changes to plan must be communicated to all relevant stakeholders in a manner that they can understand and they must be actively involved in making decisions and in quality assurance of artifacts generated in the software process. CONFLICTING GOALS Customer satisfaction is the top priority, but decisions within software projects also range between quality, time and costs. If quality is very important to a project, quality assurance activities are at the expense of timely completion and budget. If the focus is on project costs and all deadlines are met , then fewer resources remain for quality assurance. But if it is also to be delivered on time, the budget will not be kept.
3.2 PLANNING
It’s the initial phase: here all activities that are carried out before the start of software development activities can be determined. This phase is initiated by IT management who make the decisions relevant to the structure of the project: determination of requirements, financial planning, procurement, determination of conditions for all further phases. DETERMINATION OF NEEDS The reason for introducing a software system is the realization that there is a need for a system. The reasons for needing a system are diverse, typical occasions include: replacement of existing legacy systems – software systems evolve, they are usually revised to correct errors, but maintenance costs are very high, so most of the times it makes more sense to replace the existing system with a new one; in addition, the know-how for the maintenance of the existing system is often unavailable. business demands – enterprise software systems play a key role in value-adding processes. Companies develop competitive advantages, using highly specialized software systems, that’s why corporate It must react quickly to new business requirements and support the business departments with suitable systems in a targeted manner. If business requirements cannot be covered by existing software system, new systems must be provided. Technological evolution – technological evolution enables new fields of application and business that must be supported by appropriate IT solutions, therefore, changing technical constraints also lead to a need for software systems. MAKE OR BUY DECISION After the need has been identified, these questions must be answered:
- Are software solutions already available that cover the need?
- Are there standard products that can be customized to company-specific requirements?
- Does new software need to be developed? This is called a make or buy decision. Depending on the result of the make or buy decision, more specific time and resource planning takes place. PROCUREMENT Whether the order will be carried out by an external service provider or an internal IT department must be decided. In the case of external providers, activities from the development phase must be carried out in the planning phase. To bring about a decision during a hand-over as to whether the service provider fulfils all contractual obligations, the results of the requirements must already be documented when the contract is awarded. 3.3 DEVELOPMENT This phase is where all of the constructive activities required from the order to the deployment of the system take place and the system is implemented.
REQUIREMENTS ENGINEERING AND SPECIFICATION
Requirements engineering is when business requirements are further detailed and refined. After the business requirements have been determined, the required properties of the system in development are documented by a specification. SOFTWARE ARCHITECTURE AND IMPLEMENTATION The software architecture is determined based on the specification. For this purpose, the needs of the stakeholders are analyzed and weighed against each other, and the architecture definition is developed through several decisions and design activities. The program code of the system is implemented according to these specifications and the system is created accordingly. QUALITY ASSURANCE All artifacts generated during creation are checked to determine whether they meet specified requirements. However, the system can only be tested completely after implementation and integration has been finished (the program code is tested in different stages, depending on the status of the project). IT organizations have their own departments that are responsible for creating software. After the software has been implemented and tested, it is handed over to the departments responsible for operating the system 3.4 OPERATION The software system must be deployed in the operational environment and integrated into the exist8ing application landscape. The security and availability of the system must be guaranteed so that all users can work productively with the system as expected. OPERATIONAL ENVIRONMENT PROVISIONING In the operation phase work on the program is stopped and the system is used actively by its users. This means that the security risk also increases: the more people that have access to the system , the greater the risk of system, attacks or fraud. In addition, no data should be lost in the event of a hardware failure or the occurrence of a software error, and at the same time, the system should be able to cope with load peaks if necessary, but should only use as many resources as it truly needs when operating under normal requirements. The aim in operation is to ensure the application’s quality requirements, such as security, availability, and scalability. This means that the department responsible for operation must provide the appropriate infrastructure. During operation, long-term stability must be ensured, this results in a conflict between development and operation because development aims to quickly add functions to software systems. On the other hand, there must be a quick reaction to business requirements, but on the other the system should run reliably and safely. INTEGRATION After development, enterprise software systems must be deployed in the operational environment. In addition to being installed in that environment, the system must be integrated into the application landscape, which means that it must be connected to an existing system using the technical interfaces provided by the developers. The new system is only connected to other systems in the operational environment after all tests have been completed, so that real data in operational system are not accidentally changed during development.
REMOVAL
Since systems within an application landscape are connected to one another via technical interfaces, all dependencies of the application beings switched off must be identified and resolved. Every actively used technical interface of the old system must be covered with a new or an alternative existing one. In the case of very old systems the extraction is very critical: technical dependencies must be identified and the system behaviour at the interfaces must be reproduced in the event of a system replacement. The basis for this is usually the documentation , however, id the documentation is outdated and incomplete, dependencies can only be identified with reverse engineering or testing the system context while the legacy system is detached. If there is no documentation the program code must be analyzed and the behaviour of the new system must be specified with the results: this requires expert knowledge of the technologies used in the legacy system and unfortunately there is a high chance that those knowledgeable have already left the company. DATA MIGRATION If data are stored in the legacy system, they might be migrated as part of the shutdown, which means that the data in the old system must be transferred to another system for further use. One challenge when migrating data is finding an appropriate mapping of the old data schema to the new data schema, another one is the amount of data to be transferred: even when transferring millions of contract data there must be no mistake(sometimes it’s more economical to dissolve the old contracts or to ha customers switch to a new one). CONTRACT TERMINATION In order to operate a software system, an appropriate operational environment must be provided an maintained. The infrastructure must be analyzed to determine whether term-based licenses and usage rights have been acquired. Corresponding contracts must be terminated, or they might not be automatically extended. Maintenance contracts with external service providers must also be taken into account. RETRAINING IT management must also ensure that employees responsible for the operation and maintenance of legacy applications find other tasks. Programs for retraining employees must be designed and implemented in advance.
UNIT 4 – REQUIREMENTS ENGINEERING AND SPECIFICATION
WHAT I NEED TO KNOW
- Explain what requirements engineering is and who is involved
- Identify the activities that are carried out in requirements engineering and explain how they are related
- Understand what a specification is and how it Is used in software engineering
- Define the system properties that are described in a specification 4.1 REQUIREMENTS ENGINEERING Before the construction of the software can begin, the end goal of the system must be determined based on that goal, the system functions must be described in detail so that the development team can create and implements a suitable architecture. Based on this goal, all functions and properties of the system must be determined gradually, the system should support this after the development has been completed.
The necessary functions and properties are called requirements. The activities for determination, documentation, negotiation, and administration are summarized under the term “requirements engineering”. According to the CPRE (Certified professional for Requirements Engineering) Glossary, requirements engineering has the following goals:
- Knowing the relevant requirements, achieving a consensus, documenting them according to given standards and managing them systematically
- Understanding and documenting the stakeholders desires and needs
- Specifying and managing requirements to minimize the risk of delivering a system that does not meet them Several people are always involved in RE activities and must cooperate with one another. All people involved are called “stakeholders”. Requirements engineering takes place in several cycles, by carrying out RE activities several times, requirements for the system are determined and refined. According to the CPRE, Re comprises 4 core activities:
- Elicitation
- Documentation
- Validation
- Managements of requirements No fixed sequence can be described for these activities, because a responsible requirements engineer decides what type of activity will take place next, depending on the situation. REQUIREMENTS ELICITATION The aim of requirements elicitation is to identify the system requirements that are needed to achieve the goal. The requirements must be recognized and understood in the level of detail required. Example At the start of the project, it is important to determine all relevant basic functional areas without going into details. The more advanced a project is, the more detail is need about the individual requirements.. The systematic elicitation of requirements is divided into four steps:
- Determine the system context (it must be clear which stakeholders and other systems are directly dependent on the creating system);
- Determine sources for requirements (typical sources are stakeholders, documents and other systems);
- Select suitable elicitation techniques
- Apply the techniques REQUIREMENTS DOCUMENTATION The aim of requirements documentation is to ensure that the current state of knowledge is secure for all stakeholders and that everyone involved can obtain an overview at any time. To document complex structures and relationships, graphic models are often used. The specific form of documentation, however, always depends on the type of requirements that are to be documented , the
USAGE OF A SPECIFICATION WITHIN SOFTWARE DEVELOPMENT
Determined business requirements are expanded and refined in the specification to include technical requirements. The result is a business-technical specification, based on which, the system design is created and the system is implemented. Test cases are also created based on the specification for the various test levels, in which the software system is tested for compliance with the requirements. Because the specification is both the basis for realizing the system (design and implementation) and the basis for the formulation of various test cases, misunderstandings of or errors in the specification have far-reaching effects on the entire project. To specify the technical requirements as clearly and measurably as possible, there are many means of representation in software engineering (e.g., software models or notations). From a technical point of view, the specification of a system provides the technically detailed framework for design decisions. A specification does not decide how the system must be constructed internally, but only describes the externally visible system properties. From the point of view of the specification, the system is a black box of which the internal structure is unknown. SPECIFICATION ELEMENTS A specification makes statements about what a system must be able to do. It describes the externally visible functional behavior of a system. Elements for specifying the functional behavior and properties of a system are:
- Data model (contains the business objects that are processed in the system and their relationship to one another, examples include the claim report, insurance application, and customer data)
- Business functions (this is a functional description of the system’s tasks or the specified component, examples include an algorithm for calculating premiums and the procedure for terminating or concluding a contract)
- Business rules (these are rules for a business object that must not be violated, examples include that the start date of the contract must be before the end of the contract, and the total of the shopping cart must not be negative).
Quality requirements and constraints in the specification are refined on a technical level and they are made verifiable, for example, through measurable metrics. The system must comply with technical and organizational constraints, such as guidelines, standards, laws, and style guides. SPECIFICATION OF GRAPHICAL USER INTERFACES (GUI) User interface specifications define specific requirements for the following aspects:
- contents and structure of individual dialogues, which are detailed specifications on type, size, position, color, and content of user interface (UI) elements, for example, input fields, texts, buttons, and images
- input validation, which is the specification of the rules to check input fields for business plausibility
- dialogue flow, which is the specification of how the user is guided through the UI, depending on the input and actions of the user GUIs are specified both visually and textually. The visual specification defines the appearance of the UI elements used, their arrangement on a window frame, and the relationships to business objects and business functions. Such visual specifications can include sketches or screenshots of UI prototypes, as well as simple diagrams that show the dialogue flow. The textual specification details relationships that cannot be directly expressed visually or whose visualization would make the overview more difficult. These include the rules for activating and
deactivating UI elements, validation rules, and dialog flow conditions.
SPECIFICATION OF THE SYSTEM STRUCTURE AND BEHAVIOR
The specification of the structure and the behavior of the system can be divided into four steps:
- Identification and specification of functional components
- Specification of business data models
- Specification of business rules
- Specification of technical interfaces for data exchange Components A specification does not describe the software system as a whole. Depending on the specific project situation, only a very specific part of the system is relevant. Complex software systems are therefore divided into components, with each component being an independent software unit that can be combined to form a software system based on agreed interfaces with other components. As a result, specifying components means the following:
- identifying components and their relations to each other (e.g., shopping cart, article, and customer)
- describing functional responsibilities of components (e.g., extension of the term of the contract and calculation of the total amount)
- describing the processes and the logical structure of the messages exchanged at the interfaces of components Business data models With business data models, key entities of a business (or business objects) and their interrelationships are specified and defined uniformly for all parties involved. With the help of software models the structure, composition, and relationships between different business entities are specified. Based on business data models, the exchangeability of components can be guaranteed, especially in complex systems in which the
