Software Engineering - Unit Wise Questions

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.

System development life cycle is a very important method to develop an informative system. System development life cycle consist of six step and involves different persons. A system development life cycle work as an iterative model. Any change that is required in the system at any stage, the system development life cycle provide this facility to move back at any step to meet the requirements of the user’s.

The steps of system development life cycle are as follow:

1. Preliminary investigation/system planning: Preliminary investigation is the first step of system development life cycle. In this step we interview the user. The preliminary investigation step involves to finds a user requirement and present problem in the current system. In this step we determine the resources or technologies, the cost of the software. If the proposed system is accepted by the user then next phase is started otherwise repeat this step again and again to meet the user requirement.

2. Requirement analysis: In this step, system analyst study the operation of the system and their relationship within an outside the system, and study that where improvement are required and how system work. Requirement specification document is produce in this step.

3. System design: In this step new system is design to meet the requirements of the user. The design of a new system depends on the requirements indentified in system analysis phase. System design defines the display of the system, the output of system.

4. Software development: Actual coding of the program is done in this step. The program is checked by using a dummy data. Documentation is prepared to explain certain procedure.

5. System testing and integration: Program is tested individually to check the develop program work according to the requirement. After individual testing the program module are integrated and then integrated module is tested to check whether system is work according to specification. The system is checked with actual data by real user’s, and the result of the process is examines to ensure that the result is correct or not. If result is not correct or not according to requirement then adjustment is made in the program.

6. System implementation: In this step, the develop system is install and hand over to the user, and system user's are trained to operate the system carefully.

7. System maintenance: Maintenance of the system depends upon on modification and enhancements of the system. Maintenance of the system means that the current system working is effective even if system environment such as hardware, software is modified. The current system must up- to- date regularly.

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.

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.

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.

Components of Software:

There are three components of the software:

1. Program:
   A computer program is a list of instructions that tell a computer what to do.
2. Documentation:
   Source information about the product contained in design documents, detailed code comments, etc.
3. Operating Procedures:
   Set of step-by-step instructions compiled by an organization to help workers carry out complex routine operations.

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.

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.

Generic products and Bespoke products

Generic Products: These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. (i.e. developed to be sold to a range of different customers). e.g. Databases, Office packages, Drawing Packages etc.

Bespoke (custom) Products: These are the systems which are commissioned by a particular customer. A software contractor develops the software especially for that customer. (i.e. developed for a single customer according to their specification). e.g.: Control system for electronic device, software to support particular business process.

Functional and Non-functional system properties

Functional Property: These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.

Non-functional Property: These relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable. Examples are reliability, performance, safety, and security.

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.

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.

Software engineering focus on the following challenges:

i. Heterogeneity Challenge:  Every organization is required to operate as a distributed system across the network that includes different types of computer and with different types of supporting system. The heterogeneity challenge is the challenge of developing software that is flexible enough to cope with heterogeneous system.

ii. Delivery Challenge: Traditional software engineering techniques are time consuming. The time they take is required to achieve software quality. However, business organization today must be responsive and change very rapidly. Their supporting software must change equally. The delivery challenge is the challenge to provide the software within short time without compromising software quality.

iii. Trust Challenge: Trust challenge is to develop a technique that demonstrates that software can be trusted by its user.

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.

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:

The process starts with an analysis phase. During this phase, the system is analysed using automated tools to discover its structure. In itself, this is not enough to re-create the system design. Engineers then work with the system source code and its structural model. They add information to this which they have collected by understanding the system. This information is maintained as a directed graph that is linked to the program source code.

Information store browsers are used to compare the graph structure and the code and to annotate the graph with extra information. Documents of various types such as program and data structure diagrams and traceability matrices can be generated from the directed graph. Traceability matrices show where entities in the system are defined and referenced. The process of document generation is an iterative one as the design information is used to further refine the information held in the system repository.

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

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.

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.

A software process model is an abstract representation of a process that presents a description of a process from some particular perspective. Process models may contain activities, which are part of the software process, software product, and the roles of people involved in software engineering. Some examples of the types of software process models that may be produced are:

1. A workflow model: This shows the series of activities in the process along with their inputs, outputs and dependencies. The activities in this model perform human actions.
2. 2. A dataflow or activity model: This represents the process as a set of activities, each of which carries out some data transformations. It shows how the input to the process, such as a specification is converted to an output such as a design. The activities here may be at a lower level than activities in a workflow model. They may perform transformations carried out by people or by computers.
3. 3. A role/action model: This means the roles of the people involved in the software process and the activities for which they are responsible.

There are several various general models or paradigms of software development:

1. The waterfall approach: This takes the above activities and produces them as separate process phases such as requirements specification, software design, implementation, testing, and so on. After each stage is defined, it is "signed off" and development goes onto the following stage.
2. Evolutionary development: This method interleaves the activities of specification, development, and validation. An initial system is rapidly developed from a very abstract specification.
3. Formal transformation: This method is based on producing a formal mathematical system specification and transforming this specification, using mathematical methods to a program. These transformations are 'correctness preserving.' This means that you can be sure that the developed programs meet its specification.
4. System assembly from reusable components: This method assumes the parts of the system already exist. The system development process target on integrating these parts rather than developing them from scratch.

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.

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

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.

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.

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.

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

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. 

A software process is a set of related activities that leads to the production of the software. These activities may involve the development of the software from the scratch, or, modifying an existing system.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main functionalities of the software and the constrains around them.

2. Software design and implementation: The software is to be designed and programmed.

3. Software verification and validation: The software must conforms to it’s specification and meets the customer needs.

4. Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.

A software process model is the abstract representation of a software process. It is a structure of a software process present the description of a process. Each process model represents a process from a particular perspective.

Examples of process perspectives:

• Workflow perspective represents inputs, outputs and dependencies.
• Data-flow perspective represents data transformation activities.
• Role/action perspective represents the role/activities of the people involved in software process.

There are several process models are available

1.      Waterfall model

2.      Generic process model

3.      Incremental model

4.      Agile process model

5.      Prototyping model

6.      Spiral model

7.      Iterative development model, etc.

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.

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

Software specification

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. To develop the software system we should have clear understanding of Software system. To achieve this we need to continuous communication with customers to gather all requirements.

Software validation

Software validation is the process of checking the software to ensure that it works exactly according to the requirement specification. During software validation process, the software is tested with different types of users on actual working data. If software works properly with specified environment and actual operating data, then it is said to that the software confirms user requirement specification. It involves checking process such as inspection and reviews at the stage of the software process from the user requirement definition to program development. The majority of validation costs are incurred after implementation, when the operational system is tested. System should not be tested as a single unit. It should be performed in different stage.

Software evolution

Software Evolution refers to the process of developing software initially, then timely updating it for various reasons, i.e., to add new features or to remove obsolete functionalities etc. The evolution process includes fundamental activities of change analysis, release planning, system implementation and releasing a system to customers. 

The cost and impact of these changes are accessed to see how much system is affected by the change and how much it might cost to implement the change. If the proposed changes are accepted, a new release of the software system is planned. During release planning, all the proposed changes (fault repair, adaptation, and new functionality) are considered.  A design is then made on which changes to implement in the next version of the system. The process of change implementation is an iteration of the development process where the revisions to the system are designed, implemented and tested. 

Fig: Software evolution

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.

In an incremental model, customers identify, in outline, the services to be provided by the system. They identify which of the services are most important and which are least important to them. A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality. The allocation of services to increments depends on the service priority with the highest priority services delivered first.

Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail, and that increment is developed. During development, further requirements analysis for later increments can take place, but requirements changes for the current increment are not accepted.

Once increment is completed and delivered, customers can put it into services they can experiment with the system that helps to clarify their requirements for later increments and for later versions of the current increment. As new increments are completed, they are integrated with existing increments so that the system functionality improves each delivered increment. The common services may be implemented early in the process or may be implemented incrementally as functionality is required by an increment.

(In incremental model, rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve).

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.

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.

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.

Evolutionary prototyping

In this method, 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

Throw-away prototyping

Fig: Throw-away prototyping model

When a system is produced using the evolutionary development model, features tend to be added without regard to an overriding design. With each modification, the software becomes increasingly disorganized. System maintenance hampered by these problems, as it is harder identify the source of bugs in poorly designed systems. Also, keeping the documentation up to date over successive "evolution" is uncommon. Poor documentation also makes maintenance more difficult.

• It leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the full system was designed.
• there results incomplete or inadequate problem analysis.

:Large systems are usually developed by different teams and these require a common reference framework (the system requirements) for developing the system. Throwaway prototypes can be used to help develop and validate these requirements to increase confidence that these are appropriate.

Large systems usually have a long lifetime, so maintainability is an important issue. Since prototypes generally undergo many changes during development, the resultant loss in design integrity ("structurdness") can make maintenance very difficult. So throwaway prototypes is used.

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.

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.

Answered by Sneha

The difference between V- model and Spiral model are as follows:- V - MODEL 1. V model is software development model but development and testing are not concurrent. 2. In V-model testing activities start with the first stage. 3. Cost of V-model is expensive. 4. Flexibility of V model is little flexible. 5. Guarantee of success through V model is high. 6. User involvement in V-model is also only in beginning. 7. It is not iterative. Spiral Model 1. Spiral model is a software development model and is made with features of incremental, waterfall or evolutionary prototyping models. 2. Testing is done in spiral model at the end of the engineering phase. 3. While cost of spiral model is also very expensive. 4. Flexibility to change in spiral model is not that difficult. 5. Guarantee of success through Spiral model is low. 6. In this user Involvement is only at the beginning. 7. It is iterative

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

Requirement engineering is the process of defining, documenting and maintaining the requirements in the engineering design process. The requirement engineering process consists of the following activities:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

Requirement engineering process:

Requirement engineering is the process of defining, documenting and maintaining the requirements in the engineering design process. The requirement engineering process consists of the following activities:

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.

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.

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.

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.

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.

Requirement elicitation is the process of collecting the requirements of a system or requirement gathering from user, customers and stakeholders by conducting meetings, interviews, questionnaires, brainstorming sessions, prototyping etc.

 Requirement elicitation techniques are:
1. Document analysis: Document analysis is one of the most helpful elicitation techniques in understanding the current process. Documents like user manuals, software vendor manuals, process documents about the current system can provide the inputs for the new system requirements.

2. Observation: This elicitation technique helps in collecting requirements by observing users or stakeholders. This can provide information about the exiting process, inputs and outputs. There are two kinds of observations — active and passive. In active observation, the business analyst directly observes the users or stakeholders, whereas in passive observation the business analyst observes the subject matter experts.

3. Interview: An interview is a systematic approach to elicit information from a person or group of people. In this case, the business analyst acts as an interviewer. An interview provides an opportunity to explore and/or clarify requirements in more detail. Without knowing the expectations and goals of the stakeholders it is difficult to fulfil requirements.

4. Brainstorming: Brainstorming is an efficient way to define their requirements. Users can come up with very innovative ideas or requirements. This can help gather ideas and creative solutions from stakeholders in a short time. Users or stakeholders can come up with ideas that they have seen or experienced elsewhere. These ideas can be reviewed and the relevant ones can then be included in the system requirements.

5. Questionnaires: Questionnaires are useful when there is a lot of information to be gathered from a larger group of stakeholders. This enables the business team to gather requirements from stakeholders remotely. The design of the questionnaire is very important, since it can influence the answers that people provide.

6. Prototyping: Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.

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.

Two fundamental methods 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.

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:

The users, customers or other stakeholders involved in the software development do not know all the features and behavior they need to have in the software at the time of requirements gathering. End-users at first encounter are most likely to give unrealistic requirements or requirements that are filled with ambiguities. The term elicitation is a pointer to the fact that good requirements cannot be obtained simply by asking the user, customer or stakeholders what they want. Requirements elicitation therefore calls for multiple interviews, questionnaires, user observations, brainstorming sessions and lots of prototypes. This is why requirements elicitation is difficult.

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

6. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final software meets those requirements. The requirements are verified with the help of reviews.

7. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition in future development or enhancement documentation.

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.

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.

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.

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.

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.

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.

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.

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.

Systems design is the process of defining elements of a system like modules, architecture, components and their interfaces and data for a system based on the specified requirements. It is the process of defining, developing and designing systems which satisfies the specific needs and requirements of a business or organization.

System design process:

1. Architectural design, the sub system making the system and their relationship are identified.

2. Abstract specification, for each sub system, an abstract specification of its services and constraints is produced.

3. Interface design, for each sub system, its interfaces with others is designed.

4. Component design: services are allocated to the component and the interfaces for this component is designed.

5. Data structure design: the data structure used in this system are designed in detail.

6. algorithm design: the algorithm used in this system are designed in detail.

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.

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.
  

The advantages of designing and documenting software architecture:

1. Stakeholder communication: Architecture may be used as a focus of discussion by system stakeholders.

2. System analysis: Well-documented architecture enables the analysis of whether the system can meet its non-functional requirements.

3. Large-scale reuse: The architecture may be reusable across a range of systems or entire lines of products.

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.

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.

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.

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

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.

Software design is the process to transform the user requirements into some suitable form, which helps the programmer in software coding and implementation. During the software design phase, the design document is produced, based on the customer requirements as documented in the SRS document. Hence the aim of this phase is to transform the SRS document into the design document. 

Following are the principals and design concept of software design:

1. Software design should correspond to the analysis model: Often a design element corresponds to many requirements, therefore, we must know how the design model satisfies all the requirements represented by the analysis model. 2. Choose the right programming paradigm: A programming paradigm describes the structure of the software system. Depending on the nature and type of application, different programming paradigms such as procedure oriented, object-oriented, and prototyping paradigms can be used. The paradigm should be chosen keeping constraints in mind such as time, availability of resources and nature of user's requirements. 3. Software design should be uniform and integrated: Software design is considered uniform and integrated, if the interfaces are properly defined among the design components. For this, rules, format, and styles are established before the design team starts designing the software. 4. Software design should be flexible: Software design should be flexible enough to adapt changes easily. To achieve the flexibility, the basic design concepts such as abstraction, refinement, and modularity should be applied effectively. 5. Software design should ensure minimal conceptual (semantic) errors: The design team must ensure that major conceptual errors of design such as ambiguousness and inconsistency are addressed in advance before dealing with the syntactical errors present in the design model. 6. Software design should be structured to degrade gently: Software should be designed to handle unusual changes and circumstances, and if the need arises for termination, it must do so in a proper manner so that functionality of the software is not affected. 7. Software design should represent correspondence between the software and real-world problem: The software design should be structured in such away that it always relates with the real-world problem. 8. Software reuse: Software components should be designed in such a way that they can be effectively reused to increase the productivity.

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. There are two types of control models: centralized and event-based control 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) DFD

A data flow diagram (DFD) is a tool that depicts the flow of data through a system and the work or processing performed by that system. It shows how data enters and leaves the system, what changes the information, and where data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a communication tool between a system analyst and any person who plays a part in the order that acts as a starting point for redesigning a system.

Data Flow Diagrams are either Logical or Physical.

• Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system. For example in a Banking software system, how data is moved between different entities.
• Physical DFD - This type of DFD shows how the data flow is actually implemented in the system. It is more specific and close to the implementation.

b) Data Dictionary

It is a structured repository of data. Although we give descriptive names to the data flows and data stores in a DFD, it does not give the details. Hence to keep the details of the contents of data flows and data stores we require a Data Dictionary. Data Dictionary is a structured repository of data. It clearly documents the list of contents of all data flows and data stores. The three concepts to be defined are:

1. Data Elements:  This is the smallest unit of data. Further decomposition is not possible. For example, STUDENT_NAME. Each data element has a data type that defines what class of data can be stored in that data element and domain that defines what values a data element can legitimately take on.

2. Data Structure: This is a group of Data Elements which together form as a single unit of a data flow.

3. Data flows and Data stores: Data flows are data structures in motion. Data flows can be described in terms of three types of data structures: sequence (a group of data elements that occur one after another), selection (one or more data elements from a set of data elements), and repetition (one or more data elements). Data Stores are data structures in store.

c) Estimation Techniques

The Estimation is prediction or a rough idea to determine how much effort would take to complete a defined task. Here the effort could be time or cost. Some estimation techniques are:

• Expert Judgement
• COCOMO model
• Functional point method
  

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.

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

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

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

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:

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

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

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

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.

Inspection process is a formal process that is carried out by a team of at least four people: author, reader, tester and moderator. Team members systematically analyze the code and point out possible defects. The reader reads the code aloud to the inspection team, the tester inspects the code from a testing perspective and the moderator organizes the process.

    Fig: Inspection Process

An inspection process passes through the following stages:
1. Planning: The moderator plans the activities to be performed during inspection.

2. Overview: Disseminate information regarding the background of the product under review.

3. Individual preparation: Identify occurrence of a certain defect.

4. Inspection meeting: During this phase, the reader reads code, and the inspector tries to point out the defects.

5. Rework: Based on inspection meeting, the moderator makes necessary change to the product.

6. Follow up: The changes made are thus reviewed by the author.

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. 

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

Verification is the process of evaluating the product during the development to find out whether they meet the specific requirements (functional and non-functional requirements).

Validation is the process of checking the product after development to determine whether software meets the customer expectations and requirements.

The ultimate goal of verification and validation process is to establish confidence that the software system is "fit for purpose".

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.

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

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.

Security assessment is a measurement of the security posture of a system or organization. The security posture is the way information security is implemented. Security assessments are risk-based assessments, due to their focus on vulnerabilities and impact.

The assessment of system security is increasingly important as more and more critical systems are Internet-enabled and so can be accessed by anyone with a network connection. There are daily stories of attacks on web-based systems, and viruses and worms are regularly distributed using Internet protocols. The verification and validation processes for web-based systems must focus on security assessment, where the ability of the system to resist different types of attack is tested.

Approaches to security checking:

1. Experience-based validation: In this case, the system is analyzed against types of attack that are known to the validation team. This type of validation is usually carried out in conjunction with tool-based validation. This approach may use all system documentation and could be part of other system reviews that check for errors and omissions.

2. Tool-based validation: In this case, various security tools such as password checkers are used to analyze the system. Password checkers detect insecure passwords such as common names or strings of consecutive letters.

3. Tiger teams: In this case, a team is set up and given the objective of breaching the system security. They simulate attacks on the system and use their ingenuity to discover new ways to compromise the system security.

4. Formal verification: A system can be verified against a formal security specification. It is very difficult for end-users of a system to verify its security.

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.