Software Engineering 2074

Software engineering is an engineering discipline that is concerned with all aspects of software production. Software engineering focus on cost effective development of high-quality software system. The result of software engineering is an effective and reliable software product.

System engineering is an interdisciplinary field of engineering and engineering management that focus on how to design and manage complex system over their life cycle.

Difference between software engineering and system engineering

• Software engineering highly focuses on implementing quality software while system engineers highly concern about the users and domains.
• Software engineering includes in computer science or computer based engineering background while system engineering may covers a broader education area includes Engineering, Mathematics and Computer science.).
• Software engineers focus solely on software components while system engineering deals with a substantial amount of physical component of computers.
• Software Engineering deals with designing and developing software of the highest quality, while Systems Engineering is the sub discipline of engineering, which deals with the overall management of engineering projects during their life cycle.
• Software engineering techniques such as use-case modeling and configuration management are being used in the systems engineering process.

Spiral Model is a risk-driven software development process model. It is a combination of waterfall model and iterative model. Spiral Model helps to adopt software development elements of multiple process models for the software project based on unique risk patterns ensuring efficient development process.

In spiral model, total software development process activities are divided into four groups as shown in figure below:

1. Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposed in this quadrant. 
   
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution are identified and the risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution. 
   
3. Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available. 
   
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next phase is started. 

Advantages:

• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.

Disadvantages:

• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small projects.
• Process is complex
• Spiral may go on indefinitely.

Risk management is the identification, evolution and prioritization of risks followed by coordination and economical application of resources to minimize, monitor and control the probability or impact of unfortunate events or to maximize the realization of opportunities. The risk management involves anticipating risks that might affect the project schedule or the quality of software being developed and taking appropriate action to avoid risk.

Risk management process:

1) Risk identification:

    Possible project, product, and business risks are identified.

2) Risk analysis:

    The like hood and consequence of these risks are assessed.

3) Risk planning:

    Plans to address the risk either by avoiding it or minimizing its effect on the project are drawn up

4) Risk monitoring:

    Risk is constantly assessed and plans for risk avoidance.

The risk management process is an iterative process which continues throughout the project. Once an initial set of plans are drawn up, the situation is monitored. As more information about the risk becomes available, the risk has to be analyzed and new priorities are established. The risk avoidance and contingency plans may be modified as new risk information emerges. Manager should document the outcomes of the risk management process in a risk management plan. This should include a discussion of the risk faced by the project, analysis of these risks and plans that are required to manage these risks.

The requirement for a system are the descriptions of what the system should do - the services that it provides and the constraints on its operation. Requirement may range from a high-level abstract statement of a services or of a system constraint to detailed mathematical specification.

Software requirement process:

Fig: The requirements engineering process.

1. Feasibility study: An estimate is made of whether the identified can be achieved using the current software and hardware technologies, under the current budget, etc. The feasibility study should be cheap and quick; it should inform the decision of whether or not to go ahead with the project.

2. Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussions with stakeholders, etc. This may involve the development of one or more system models and prototypes that can help us understanding the system to be specified.

3. Requirements specification: It’s the activity of writing down the information gathered during the elicitation and analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document; user and system requirements.

4. Requirements validation: It’s the process of checking the requirements for realism, consistency and completeness. During this process, our goal is to discover errors in the requirements document. When errors are found, it must be modified to correct these problems.

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.

Fig: Formal specification in software process

The system requirements and system design are expressed in details and carefully analyzed and checked before implementation begins. A formal specification of software is developed after the system requirement have been specified but before the detailed system design. The main benefit of formal specification is its ability to uncover problem and ambiguities in the requirements specification. It forces to system analysis to remove errors and inconsistencies in the requirement specification.

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.

Two fundamental techniques for formal specification are:

1. Algebraic Approach: In algebraic approach, system is described in terms operation and their relationship. It consists of two parts: signature, which determines syntax of operation and an equation, which defines the semantics of operations.

2. Model-Based Approach: In model based approach, the abstract model of system is built using mathematical construct such as set theory, function theory and logic. It specifies the operations performed on abstract model.

Client server model is a system model where the system is organized as a set of services and associated servers and clients that access and use the services.

The major components of this model are:

1. A set of servers that offer services to other sub-systems. Examples of servers are print servers that offer printing services, file servers that offer file management services and a compile server, which offers programming language compilation services.

2. A set of clients that call on the services offered by servers. There may be several instances of a client program executing concurrently.

3. A network that allows the clients to access these services. 

Clients may have to know the names of the available servers and the services that they provide. However, servers need not know either the identity of clients or how many clients there are. Clients access the services provided by a server through remote procedure calls using a request-reply protocol.

Advantages:

• Distribution of data is straightforward.
• Makes effective use of networked system.
• May require cheaper hardware.
• Easy to add new servers or upgrade existing servers.

Disadvantages:

• No shared data model so sub-system use different data organization. Data interchange may be inefficient.
• Redundant management in each server.
• No central register of names and services - it may be hard to find out what servers and services are available.

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

The simplest form of software re-engineering is program 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

The above figure illustrates the process of source code translation. There may be no need to understand the operation of the software in detail or to modify the system architecture. The analysis involved can focus on programming language considerations such as the equivalence of program control constructs. Source code translation is only economically realistic if an automated translator is available to do the bulk of the translation. This may be a specially written program, a bought-in tool to convert from one language to another or a pattern matching system. In the latter case, a set of instructions how to make the translation from one representation to another has to be written. Parameterised patterns in the source language are defined and associated with equivalent patterns in the target language.