Software Engineering 2069

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.

Characteristics of software:

• Functionality: Refers to the degree of performance of the software against its intended purpose.

• Reliability: Refers to the ability of the software to provide desired functionality under the given conditions.

• Usability: Refers to the extent to which the software can be used with ease.

• Efficiency: Refers to the ability of the software to use system resources in the most effective and efficient manner.

• Maintainability: Refers to the ease with which the modifications can be made in a software system to extend its functionality, improve its performance, or correct errors.

• Portability: Refers to the ease with which software developers can transfer software from one platform to another, without (or with minimum) changes.

Prototyping is a rapid, iterative, and incremental process of systems development in which requirements are converted to a working system that is continually revised through close work between the development team and the users. 

1. Requirements gathering and analysis: A prototyping model starts with requirement analysis. In this phase, the requirements of the system are defined in detail. During the process, the users of the system are interviewed to know what is their expectations from the system.

2. Quick design: In this stage, a simple design of the system is created. However, it is not a complete design. It gives a brief idea of the system to the user. The quick design helps in developing the prototype.

3. Build a Prototype: In this phase, an actual prototype is designed based on the information gathered from a quick design. It is a small working model of the required system.

4. Initial user evaluation: In this stage, the proposed system is presented to the client for an initial evaluation. It helps to find out the strength and weaknesses of the working model. Comment and suggestions are collected from the customer and provided to the developer.

5. Refining prototype: If the user is not happy with the current prototype, we need to refine the prototype according to the user’s feedback and suggestions. This phase will not over until all the requirements specified by the user are met. Once the user is satisfied with the developed prototype, a final system is developed based on the approved final prototype.

6. Implement Product and Maintain: Once the final system is developed based on the final prototype, it is thoroughly tested and deployed to production. The system undergoes routine maintenance for minimizing downtime and prevent large-scale failures.

The COCOMO (Constructive Cost Model) is one of the most popularly used software cost estimation models i.e. it estimates or predicts the effort required for the project, total project cost and scheduled time for the project. This model depends on the number of lines of code for software product development.

COCOMO model has three types:

1. The Basic COCOMO

It is the one type of static model to estimates software development effort quickly and roughly. It mainly deals with the number of lines of code and the level of estimation accuracy is less as we don’t consider the all parameters belongs to the project. The estimated effort and scheduled time for the project are given by the relation:

Effort (E) = a*(KLOC)b  MM

Scheduled Time (D) = c*(E)d  Months(M)

Where,

• E = Total effort required for the project in Man-Months (MM).
• D = Total time required for project development in Months (M).
• KLOC = the size of the code for the project in Kilo lines of code.
• a, b, c, d = The constant parameters for a software project.

2. The Intermediate COCOMO

The intermediate model estimates software development effort in terms of size of the program and other related cost drivers parameters (product parameter, hardware parameter, resource parameter, and project parameter) of the project. The estimated effort and scheduled time are given by the relationship:

Effort (E) = a*(KLOC)b *EAF  MM
Scheduled Time (D) = c*(E)d  Months(M)

EAF = It is an Effort Adjustment Factor, which is calculated by multiplying the parameter values of different cost driver parameters. For ideal, the value is 1.

3. The Detailed COCOMO

It is the advanced model that estimates the software development effort like Intermediate COCOMO in each stage of the software development life cycle process.

In evolutionary prototyping, the prototype developed initially is incrementally refined on the basis of customer feedback till it finally gets accepted.  It helps us to save time as well as effort. That's because developing a prototype from scratch for every interaction of the process can sometimes be very frustrating.

This model is helpful for a project which uses a new technology that is not well understood. It is also used for a complex project where every functionality must be checked once. It is helpful when the requirement is not stable or not understood clearly at the initial stage.

Fig: Evolutionary prototyping model

Evolutionary prototyping is used in software development due to the following reasons:

• The efforts required in developing the final system is reduced as the final system is implemented after all the specifications are clearly understood and there are fewer chances of final system being incorrect.
• It helps the customer to easily realize the required modification before final implementation of the system.
• The customer does not have to wait for a long to see the working model of the final system.
• There are more chances of the developed system is more user-friendly.
• It helps us to save time as well as effort. 
• User satisfaction is achieved.

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.

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

Two modular decomposition models covered:

• An object model where the system is decomposed into interacting objects

• A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model.

Object model

• Structure the system into a set of loosely coupled objects with well-defined interfaces.
• Object-oriented decomposition is concerned with identifying object classes, their attributes and operations.
• When implemented, objects are created from these classes and some control model used to coordinate object operations.

Advantages:

• Since objects are loosely coupled, the implementation of objects can be modified without affecting other objects.
• Objects are often representations of real-world entities so the structure of the system is readily understandable.
• As real-world entities are used in different systems, objects can also be reused.

Sequence Diagrams are interaction diagrams that detail how operations are carried out. They capture the interaction between objects in the context of a collaboration. Sequence Diagrams are time focus and they show the order of the interaction visually by using the vertical axis of the diagram to represent time what messages are sent and when.

Some basic sequence diagram notation are:

1. Class Roles or Participants: Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes.

2. Activation or Execution Occurrence: Activation boxes represent the time an object needs to complete a task. When an object is busy executing a process or waiting for a reply message, use a thin gray rectangle placed vertically on its lifeline.

3. Messages: Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks.

4. Lifelines: Lifelines are vertical dashed lines that indicate the object's presence over time.

Example: Sequence diagram for ATM 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

Testing is the process of executing a program with the aim of finding errors. To make our software perform well it should be error-free. If testing is done successfully it will remove all the errors from the software. 

Types of testing:

1. Unit Testing: It focuses on the smallest unit of software design. In this, we test an individual unit or group of interrelated units. It is often done by the programmer by using sample input and observing its corresponding outputs.

2. Integration Testing: The objective is to take unit tested components and build a program structure that has been dictated by design. Integration testing is testing in which a group of components is combined to produce output. 

3. System Testing: System testing is a software testing where a complete and integrated software is tested to verify that it meets specified requirements. It is done after integration testing. This plays an important role in delivering a high-quality product. It falls under the class of black box testing.

4. Acceptance Testing: Acceptance testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application. It has two types:

    i) Alpha testing: Alpha testing is a type of testing performed to identify bugs before releasing product to real users. It is typically done by QA people. 

    ii) Beta testing: The beta test is conducted at one or more customer sites by the end-user of the software. This version is released for a limited number of users for testing in a real-time environment .

5. Regression Testing: Every time a new module is added leads to changes in the program. This type of testing makes sure that the whole component works properly even after adding components to the complete program. 

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.

Difficulties in Reliability validation:

1. Operational profile uncertainty: The operational profiles based on experience with other systems may not be an accurate reflection of the real use of the system.

2. High costs of test data generation: It can be very expensive to generate the large volume of data required in an operational profile unless the process can be totally automated.

3. Statistical uncertainty when high reliability is specified: We have to generate a statistically significant number of failures to allow accurate reliability measurements. When the software is already reliable, relatively few failures occur and it is difficult to generate new failures.

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 consists of 4 objects:

1. System: System is used to define scope of the use case and drawn as a  rectangle.

2. Use Case: It represents the function or an action within the system. It is drawn as an oval and name with the function.

3. Actors: Actors are the users of a system. They interact with the system being designed in order to obtain some value from that interaction.

Relationships: Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.

a. User Interface Prototyping 

User interface (UI) prototyping is an iterative development technique in which users are actively involved in the mocking-up of the UI for a system. The aim of prototyping is to allow users to gain direct experience with the interface. Without such direct experience, it is impossible to judge the usability of an interface.

UI prototype involves two stages:

1. Early in the process, develop paper prototypes.

2. The design is then refined and increasingly sophisticated automated prototypes are then developed.

b. Software Inspection

Software inspection is a static verification & validation process in which a software system is reviewed to find errors, omissions and anomalies. Inspection is used to determine the defects in the code and remove it efficiently. This prevents defects and enhances the quality of testing to remove defects. This software inspection method achieved the highest level for efficiently removing defects and improving software quality.

    Fig: Inspection Process

c. Source Code Translation

The simplest form of software re-engineering is source code translation where source code in one programming language is automatically translated to source code in some other language. The structure and organisation of the program itself is unchanged. The target language may be an updated version of the original language (e.g. COBOL-74 to COBOL-85) or may be a translation to a completely different language (e.g. FORTRAN to C).

Program translation process:

Fig: Program translation process