Software Engineering 2072

Software is an organized collection of computer programs and associated documentation. A software system consist of a number of several programs, configuration files which are used to set of these programs and system documentations which describe the structure of system and user documentation which explain how to use the software.

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. Software process model is needed because it represents the order in which the activities of software development will be undertaken.  It describes the sequence in which the phases of the software lifecycle will be performed.

The reuse-oriented development is where they reuse programming or software in previous projects or existing software components. Reuse-oriented development is based on systematic reuse where systems are integrated from existing components. This development can reduce the overall cost of software development and it can also save time because each phase of the process builds on the previous phase which has already been refined. 

The general process model for reuse based development is shown in figure below:

1. Requirement Specification: All possible requirements of the system to be developed are captured in this phase.

2. Component Analysis: According to given requirement, component is selected to implement that requirement specification. That is not possible the selected component provide the complete functionality, but that is possible the component used provide some of the functionality required.

3. Requirement Modification: Information about component that is selected during component analysis is used to analysis requirement specification. Requirements are modified according to available components. Requirement modification is critical then component analysis activity is reused to find relative solution.

 4. System design with reuse: During this stage the design of the system is build.  Designer must consider the reused component and organize the framework. If reused component is not available then new software is develop.

5. Development and Integration: Components are integrated to develop new software. Integration in this model is part of development rather than separate activity.

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.

Requirements elicitation and analysis is a process of interacting with customers and end-users to find out about the domain requirements, what services the system should provide, and the other constrains.

The requirements elicitation and analysis has 4 main process:

1. Requirements Discovery: It’s the process of interacting with, and gathering the requirements from, the stakeholders about the required system and the existing system (if exist). It can be done using some techniques, like interviews, scenarios, prototypes, etc, which help the stockholders to understand what the system will be like.

2. Requirements Classification & Organization: It’s very important to organize the overall structure of the system. Putting related requirements together, and decomposing the system into sub components of related requirements. Then, we define the relationship between these components.

3. Requirements Prioritization & Negotiation: This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiations until you reach a situation where some of the stakeholders can compromise.

4. Requirements Specification: It is the process of writing down user and system requirements into a document. The requirement should be clear, easy to understand, complete and consistent.

Rapid prototyping involves creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The model then becomes the starting point from which user can re-examine their expectations and clarify their requirements. When this goal has been achieved, the prototype model is thrown away and the system is formally developed based on the identified requirements.

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.

Formal methods are intended to systematize and introduce rigor into all the phases of software development. This helps us to avoid overlooking critical issues, provides a standard means to record various assumptions and decisions, and forms a basis for consistency among many related activities. By providing precise and unambiguous description mechanisms, formal methods facilitate the understanding required to coalesce the various phases of software development into a successful endeavor.

Behavioral specification

The simple algebraic technique can be used to describe interfaces where the object state changing depending on the previous operation result. Where this condition holds we say it the behavior properties of system. The specification which is used to specify such type of system property is called behavioral specification.

The object state of the subsystem changes on the result of operations in the object or while interacting with other sub-system objects. The changes of the state of object is called behavioral characteristics of the system. The behavioral state of the formal specification is represented by model-based approach and is expressed as a state model.

Basic types of behavioral specification:

1. Abstract model specifications: defines operations in terms of well-defined mathematical model.

2. Algebraic specifications: defines operations by a collection of equivalence relations.

3. State transition specification: defines operations in terms of states and transitions.

4. Axiomatic specifications: defines operations by logical assertions.

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. Architectural design is an early stage of the system design process. It represents the link between specification and design processes and is often carried out in parallel with some specification activities. It involves identifying major system components and their communications.

Repository Model

A repository model is a system that will allow interfacing sub-systems to share the same data. Sub-system must exchange data so that they can work together effectively. This may be done in two ways:

1. All shared data is held in a central database that can be accessed by all subsystems. It is called repository model.

2. Each sub-system maintains its own database. Data is interchanged with other sub-systems by passing messages to them.

Example: CASE Toolset

Advantages:

• It is an efficient way to share large amounts of data. There is no need to transmit data explicitly from one sub-system to another.
• Sub-systems that produce data need not be concerned with how that data is used by other subsystems.
• Activities such as backup, security, access control and recovery from error are centralized.

Disadvantages:

• It is a compromise between the specific needs of each tool. Performance may be adversely affected by this compromise.
• Evolution may be difficult as a large volume of information is generated according to an agreed data model.
• Different sub-systems may have different requirements for security, recovery and backup policies. The repository model forces the same policy on all subsystems.

Control models are models deployed in software engineering that are concerned with the control flow between the subsystems. They are distinct from the system decomposition model.

Centralized Control Model

Centralized model is a formulation of centralized control in which one subsystem has overall responsibility for control and starts and stops other subsystems. It is a control subsystem that takes responsibility for managing the execution of other subsystems. Centralized models are classified into call-return and manager model.

1. Call-return Model: In call-return model, it is a model which has top-down subroutine architecture where control starts at the top of a subroutine hierarchy and moves downwards.

The call-return model is illustrated in above figure. The main program can call Routines 1, 2 and 3; Routine 1 can call Routines 1.2 or 1.2; Routine 3 can call Routines 3.1 or 3.2; and so on.

2.  Manager Model: Manager model is applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes.

Event-based Control Model

Event-based models are those in which each sub-system can respond to externally generated events from other subsystems or the system’s environment. It is a system driven by externally generated events where the timing of the events is out with the control of the subsystems which process the event.

Event-based models are classified into broadcast and interrupt-driven models.

1. Broadcast models: In these models, an event is, in principle, broadcast to all sub-systems. Any sub-system, which is designed to handle that event, responds to it.

2. Interrupt-driven models: These are exclusively used in real-time systems where an interrupt handler detects external interrupts. They are then passed to some other component for processing.

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 an online course registration 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.

Fig: The cleanroom development process

Verification and Validation planning

Validation and verification  is an expensive process and more than the half the system development budget may be spend on validation and verification process. So, careful planning is needed for validation and verification (V & V).

Fig: Test plans as a link between development and testing

It breaks down system V & V into a number of stages. Each stage is driven by tests that have been defined to check the conformance of the program with its design and specification.

We should decide on the balance between static and dynamic approaches to V & V, draw up standards and procedures for software inspections and testing, establish checklists to drive program Inspections and define the software test plan. 

Test planning is concerned with establishing standards for the testing process. It helps managers to allocate resources and estimate testing schedules, test plans are intended for software engineers involved in designing and carrying out system tests. It helps technical staff get an overall picture of the system tests and place their own work in this context.

a. 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:

b. Function point

Functional point is an element of software development which helps to approximate the cost of development early in the process. It may measure functionality from user's point of view.

Counting functional point (FP):

Step 1:

F = 14*scale,    scale varies from 0 to 5 according to character of complexity adjustment factor (CAF).

Step 2:

CAF = 0.65 + (0.01*F)

Step 3:

Calculate unadjusted functional point (UFP)

Step 4: 

Calculate functional point FP = UFP * CAF