Software Engineering 2068(II)

Software Engineering is an engineering discipline that is concerned with all aspects of software production from system specification through to maintenance. Software engineering includes activities such as software specification, software designing, software development, software validation, software deployment, software evolution. It is concerned with practicalities of developing and delivering useful software. Software engineering is not just concerned with technical process of software development but also includes activities such as software project management and the development of tools, methods and theories to support software production.

Software engineering is important for two reasons;

• More and more individuals and society rely on advanced software system. We need to be able to produce reliable and trustworthy system economically and quickly.
• It is usually cheaper in the long run to use software engineering methods, and techniques for software system rather than just write program as if it was a personal programming project.

National infrastructures and utilities are controlled by computer-based systems. We live in a world that is driven by IT. Software is a relatively low-investment, Eco-friendly, high growth global industry, a good target growth for industry for many countries. Every software exporting country have evolved a unique industry, shaped by its own resources and situation and by the particular global opportunities presented at the time. The world has moved from agricultural, industrial and post industrialization to the era of globalization and liberalization of a country. Hence information assets are seen as the key driver for economic growth, competitiveness, and business improvement. Software arena is a key strategic resume for value creation in an economy, intellectual capital and investment opportunity. Software development serves as vehicle for implementing responsive transparent start, a supportive business environment, enhanced learning environment, effective social program.

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.

Feasibility study is so important stage software life cycle as after completion of feasibility study it gives a conclusion of whether to go ahead with proposed project as it is practically feasible or to stop proposed project here as it is not right/feasible to develop or to think/analyze about proposed project again.

Along with this Feasibility study helps in identifying risk factors involved in developing and deploying system and planning for risk analysis also narrows the business alternatives and enhance success rate analyzing different parameters associated with proposed project development.

Types of feasibility study:
1. Technical Feasibility: Technical feasibility helps in accessing the current resources as well as technology that is required for accomplishing the requirements of the user in the software within the allocated budget and time. Following tasks are performed in the technical feasibility:

• Helps in determining whether the technology used is stable.
• Is the technology being demanded available? Or can the features being requested are possible to embed with the current/ available technology.
• Analyze the technical capabilities and skills of the team members of software development.

2. Operational/ Behavioral Feasibility: Behavioral feasibility is studied in order to check, whether the human or employees in the business will use it or not. Operational feasibility relies on human resources and analyzes whether the software will operate after it is developed properly or not.

3. Economic Feasibility: Economic Feasibility helps in determining whether the required software has the potential to generate financial gains for an organization. This type of study involves the cost incurred on the team of the software development, cost of study involved in conducting a feasibility study, estimated cost of software and hardware. 

4. Scheduling feasibility: It is the most important study that is used for measuring the success of the project. All the projects will fail, if not completed at specified time. In scheduling feasibility, an organization is able to estimate the time required for completing the project. The time that will be required for the development of the system, is estimated on the basis of the requirements. Once all these things are sorted, manpower is allocated their respective task and efforts are made to complete the task within the deadline.

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.

In COCOMO, projects are categorized into three types:

1. Organic – A software project is said to be an organic type if the team size required is adequately small, the problem is well understood and has been solved in the past and also the team members have a nominal experience regarding the problem.  Examples of this type of projects are simple business systems, simple inventory management systems, and data processing systems.

2. Semi-detached – A development project can be treated with semidetached type if the development consists of a mixture of experienced and inexperienced staff. Team members may have finite experience in related systems but may be unfamiliar with some aspects of the order being developed. Example of Semidetached system includes developing a new operating system (OS), a Database Management System (DBMS), and complex inventory management system.

3. Embedded – A software project with requiring the highest level of complexity, creativity, and experience requirement fall under this category. Such software requires a larger team size than the other two models and also the developers need to be sufficiently experienced and creative to develop such complex models.  For Example: ATM, Air Traffic control.

A software requirements specification (SRS) is a detailed description of a software system to be developed with its functional and non-functional requirements. The SRS is developed based the agreement between customer and contractors. It may include the use cases of how user is going to interact with software system. The software requirement specification document consistent of all necessary requirements required for project development.

Following are the five desirable characteristics of SRS:

1. Correctness: User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the system.

2. Completeness: Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the to be determined parts to as much extent as possible as well as covering all the functional and non-functional requirements properly.

3. Consistency: Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples of conflict include differences in terminologies used at separate places, logical conflicts like time period of report generation, etc.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted. In case there is a method used with multiple definitions, the requirements report should determine the implications in the SRS so that it is clear and simple to understand.

5. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain changes to the system to some extent. Modifications should be perfectly indexed and cross-referenced.

The main advantages of using an object-oriented design approach over a function-oriented approach are

1. Simplicity: Software objects model real world objects, so the complexity is reduced and the program structure is very clearly.

2. Code reuse and recycling: Object created for one program can be easily reused in other program.

3. Faster development: Reuse enables faster development.

4. Lower cost of development: The reuse of software also lowers the cost of development.

5. High-quality software: Faster development of software and lower cost of development allows more time and resource to be used in verification of the software.

6. Maintainable: OOP methods make code more maintainable. Objects can be maintained separately, making locating and fixing problems easier. 

7. Scalable: As an object's interface provides for reusing the object in new software, it also provides all the information needed to replace the object without affecting other code. This makes it easy to replace old and aging code with faster algorithms and newer technology.

8. Highly secure: Data is hidden and cannot be accessed by external functions.

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.

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.

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.

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.

A class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects.

A UML class diagram is made up of:

• A set of classes and
• A set of relationships between classes

Class
A class is a description of a group of objects all with similar roles in the system. A class notation consists of three parts:

Relationships

A class may be involved in one or more relationships with other classes. A relationship can be one of the following types:

1) Generalization: A generalization is a relationship between a parent class (superclass) and a child class (subclass). In this, the child class is inherited from the parent class.

2) Association: This kind of relationship represents static relationships between two classes.

3) Aggregation: Aggregation is a special type of association that models a whole- part relationship between aggregate and its parts.

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

b. Software validation

Validation is the process of checking the product after development to determine whether software meets the customer expectations and requirements.  It is the process of checking the validation of product i.e. it checks what we are developing is the right product. It is validation of actual and expected product. Validation is the Dynamic Testing.

Activities involved in validation:

1. Black box testing
2. White box testing
3. Unit testing
4. Integration testing

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