Software Engineering 2076

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. It is about representing a system using some kind of graphical notation, such as Unified Modeling Language (UML). Models help the analyst to understand the functionality of the system; they are used to communicate with customers.

Models can explain the system from different perspectives:

• An external perspective, where we model the context or environment of the system.
• An interaction perspective, where we model the interactions between a system and its environment, or between the components of a system.
• A structural perspective, where we model the organization of a system or the structure of the data that is processed by the system.
• A behavioral perspective, where we model the dynamic behavior of the system and how it responds to events.

Five types of UML diagrams that are the most useful for system modeling:

• Activity diagrams, which show the activities involved in a process or in data processing.
• Use case diagrams, which show the interactions between a system and its environment.
• Sequence diagrams, which show interactions between actors and the system and between system components.
• Class diagrams, which show the object classes in the system and the associations between these classes.
• State diagrams, which show how the system reacts to internal and external events.

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

The waterfall model is a sequential approach, where each fundamental activity of a process represented as a separate phase, arranged in linear order. Each phase is carried out completely (for all requirements) before proceeding to the next. The process is strictly sequential - no backing up or repeating phases. This SDLC model includes gradual execution of every stage completely. This process is strictly documented and predefined with features expected to every phase of this SDLC model.

Fig: The waterfall model

The sequential phases in Waterfall model are −

1. Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.

2. System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.

3. Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.

4. Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

5. Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.

6. Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

Merits of Waterfall model

• This model is simple to implement also the number of resources that are required for it is minimal.
• The requirements are simple and explicitly declared; they remain unchanged during the entire project development.
• The start and end points for each phase is fixed, which makes it easy to cover progress.
• It gives easy to control and clarity for the customer due to a strict reporting system.
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.

Demerits of Waterfall model

• No working software is produced until late during the life cycle.
• In this model, the risk factor is higher, so this model is not suitable for more significant and complex projects.
• This model cannot accept the changes in requirements during development.
• It becomes tough to go back to the phase.
• Since the testing done at a later stage, it does not allow identifying the challenges and risks in the earlier phase, so the risk reduction strategy is difficult to prepare.

Risk is the uncertainty which is associated with a future event which may or may not occur and a corresponding potential for loss.

A software project can be concerned with a large variety of risks. In order to be adept to systematically identify the significant risks which might affect a software project, it is essential to classify risks into different classes. The project manager can then check which risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-related problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to monitor and control a software project. It is very tough to control something which cannot be identified. For any manufacturing program, such as the manufacturing of cars, the plan executive can recognize the product taking shape.

2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and maintenance issue. It also consists of an ambiguous specification, incomplete specification, changing specification, technical uncertainty, and technical obsolescence. Most technical risks appear due to the development team's insufficient knowledge about the project.

3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing budgetary or personnel commitments, etc.

Risk analysis stage during risk management process

During the risk analysis process, we have to consider every identified risk and make a perception of the probability and seriousness of that risk. Proper risk analysis helps to control possible future events that may harm the overall project.

It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk. Instead, we should authorize the risk to one of several bands:

1. The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would cause significant delays), tolerable (delays are within allowed contingency), or insignificant.

Functional Requirements

Functional requirements are the statements of services the system should provide, how the system should react to particular input, and how the system should behave in particular situation. The functional requirements for a system should describe what the system do. These requirements depend on the type of software being developed, the expected users of the software and the general approach taken by the organization when writing requirements. Each high level functional requirement may involve several interactions or dialogues between the system and the outside world. There are many ways of expressing functional requirements for e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax.

Non-Functional Requirements

Non-functional requirements are the requirements that are not directly concern with the specific function of the system. They define system properties and constraints like readability, response time and storage requirements. It describes how the system will do it. The process of specifying non-functional requirements requires the knowledge of functionality of system, as well as the knowledge of context within which the system will operate.

Domain Requirements

Domain requirements are the requirements which are characteristic of a particular category or domain of projects. The basic functions that a system of a specific domain must necessarily exhibit come under this category. For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific.

Prototyping is a technique for building a quick and rough version of a desired system or parts of that system. The prototype illustrates the system to users and designers. It allows them to see flaws and invent ways to improve the system. It serves as a communications vehicle for allowing persons who require the system to review the proposed user interaction with the system.

Rapid prototyping techniques

Various techniques may be used for rapid development:

1. Using high level language:

• High level language include many powerful data management facilities. 
• Using high level language we can create prototype with very little programming effort.
• Some languages offer excellent UI development facilities.

2. Reuse component:

The time need to develop a prototype can be reduced if many parts of the systems can be reused rather than designed and implemented. The reusable components may also be used in the final system thus reducing its development cost.

3. Ignore error handling:

In many system as much as one-half of the software is concerned with error handling. The time need to develop a prototype can be reduced If we ignore the error while designing prototype.

4. Omit features:

Omit features which are costly and takes large time to develop. So their omission make construct of prototype quicker.

5.Ignore functionality:

Only focus on establishing an acceptable user-interface.

6. Database programming language:

It includes a database query language, a screen generator, a report generator and a spreadsheet. These may be integrated with a CASE toolset. These are cost effective for small to medium sized business system.

A formal software specification is a statement expressed in a language whose vocabulary, syntax, and semantics are formally defined. It is a technique for unambiguous specification of software to be build. The specification languages cannot be based on natural language; it must be based on mathematics because natural language specification are informal and usually contain ambiguities.

Fig: Formal specification in software process

Interface Specification

Large systems are decomposed into subsystems with well-defined interfaces between these subsystems. Specification of subsystem interfaces allows independent development of the different subsystem. Subsystem make use of other subsystem, so an essential part of specification is to define subsystem. Once the interface are agreed and defined, the subsystem can then be designed and implemented independently. Subsystem interface are often defined as a set of object or component.

Three types of interface may have to be defined:

1. Procedural interface: Used for calling the existing programs by the new programs.

2. Data Structure: Provide data passing from one sub-system to another.

3. Data representation: Ordering of bits to match with the existing system.

Formal notations are an effective technique for interface specification.

Architectural design is a process for identifying the sub-systems making up a system and the framework for sub-system control and communication. The output of this design process is a description of the software architecture.  It represents the link between specification and design processes and is often carried out in parallel with some specification activities. The architectural design process is concerned with establishing a basic structural framework that identifies the major components of a system and the communications between these components.

Architectural design process includes following activities:

• System structuring: The system is decomposed into major sub-systems and communication (e.g. data sharing) mechanisms are identified.
• Control modelling: A model of the control relationships between the sub-systems is established.
• Modular decomposition: The identified sub-systems are decomposed into lower-level modules (components, objects etc.).

Abstract Machine Model

Abstract machine model is used to model the interfacing of sub-systems. It organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. This model supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. 

It is used when building new facilities on top of existing systems; when the development is spread across everal teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security.

Example: Simple abstract machine based version management system

Advantages:

• Supports incremental development.
• Allows replacement of entire layers so long as the interface is maintained.
• Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system.

Disadvantages:

• In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it.
• Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer.
  

Modular decomposition is a process of decomposing subsystems into modules. After decomposition of the system into subsystems, subsystems must be decomposed into modules.

In object oriented model of decomposition, system is decomposed into a set of communicating objects. An object-oriented, architectural model structures the system into a set of loosely coupled objects with well defined interfaces. Objects call on the services offered by other objects.

Figure: An object model of an invoice processing system

• This system can issue invoices to customers, receive payments, and issue receipts for these payments and reminders for unpaid invoices.
• Operations, if any, are defined in the lower part of the rectangle representing the object. Dashed arrows indicate that an object uses the attributes or services provided by another object.
• An object-oriented decomposition is concerned with object classes, their attributes and their operations.
• When implemented, objects are created from these classes and some control model is used to coordinate object operations.
• The Invoice class has various associated operations that implement the system functionality.

A Use Case consists of use cases, persons, or various things that are invoking the features called as actors and the elements that are responsible for implementing the use cases. The purpose of use case diagram is to capture the dynamic aspect of a system.

Use Case Diagram captures the system's functionality and requirements by using actors and use cases. Use Cases model the services, tasks, function that a system needs to perform. Use cases represent high-level functionalities and how a user will handle the system. 

Use case diagram for library system

Cleanroom approach for software development is the way of software development in which software defects are avoided by using formal methods of development and rigorous inspection process. The objective of this approach is to development software with zero-defect.

The cleanroom approach to software development is based on five strategies:

1. Formal specification: The software to be developed is formally specified.

2. Incremental development: The software is partitioned into increments that are developed and validated separately using the Cleanroom process. These increments are specified, with customer input, at an early stage in the process.

3. Structured programming: Only a limited number of control and data abstraction constructs are used.

4. Static verification: The developed software is statically verified using rigorous software inspections. There is no unit or module testing process for code components.

5. Statistical testing of the system: The integrated software increment is tested statistically to determine its reliability. These statistical tests are based on an operational profile, which is developed in parallel with the system specification.

Fig: The cleanroom development process

a. Reliability validation

Reliability validation is the process of measuring the reliability of a system. To validate that the system meets these requirements, we have to measure the reliability of the system as seen by typical system user.

Reliability validation process:

  1. Establish the operational profile for the system.

  2. Construct test data reflecting the operational profile

  3. Test the system and observe the number of failures and the times of these failures.

  4. Compute the reliability after a statistically significant number of failures have been observed.

b. Reverse engineering

The objective of reverse engineering is to derive the design and specification of a system from its source code. It is the process of analyzing a program in an effort to create a representation of the program at a higher level of abstraction than source. The program itself is unchanged by the reverse engineering process. The software source code is usually available as the input.

Reverse engineering process: