Software Engineering 2073

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.

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. 

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.

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

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.

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

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.

Software quality assurance (SQA) is a planned and systematic plan of all actions necessary to provide adequate confidence that an item or product conforms to establish technical requirements.

Software Quality Assurance works parallel to development of a software. It focuses on improving the process of development of software so that problems can be prevented before they become a major issue. Software Quality Assurance is a kind of an Umbrella activity that is applied throughout the software process.

Software Quality Assurance have:

• A quality management approach
• Effective Software engineering technology (methods and tools)
• Formal technical reviews that are tested throughout the software process
• A multitier testing strategy
• Control of software documentation and the changes made to it.
• A procedure to ensure compliances with software development standards
• Measuring and reporting mechanisms.

Following activities are performed by an independent SQA group:

• Prepares an SQA plan for a project
• Participates in the development of the project's software process description
• Reviews software engineering activities to verify compliance with the defined software process
• Audits designated software work products to verify compliance with those defined as a part of the software process
• Ensures that deviations in software work and work products are documented and handled according to a documented procedure
• Records any noncompliance and reports to senior management

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.

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.

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