Software Engineering 2075

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.

Project planning is an organized and integrated management process, which focus on activities required for successful completion of the project. It is concerned with identifying the activities, milestones and deliverables produced by the project. Project plan should include cost of various resources required to accomplish project.

Types of project plan:

1. Quality plan:

    It describes the quality procedures and standards that will be used in a project

2. Validation plan: 

    It describes the approach, resources and schedule used for system validation

3. Configuration management plan:  

    It describes the configuration management procedures and structures to be used.

4. Maintenance plan:

    It predicts the maintenance requirements of the system, maintenance costs and effort required.

5. Staff development plan:  

    It describes how the skills and experience of the project team members will be developed.

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. 

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

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.

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.

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.

Top down and Bottom up testing are the type of integration testing.

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) Security assessment

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

 b) Expert judgment

It is a software cost estimation technique. In expert judgement technique, one or more experts in both software development and the application domain use their experience to estimate the software cost. The estimation process iterates until an agreed estimate is reached.

Advantages:

• Relatively cheap estimation method.
• Can be accurate if experts have direct experience of similar system.

Disadvantages:

• Very inaccurate if there are no experts.

c) System and their environment

A group of components which are interconnected and interact to fulfill certain objective is called a system. A system mainly consists of input, process, output and feedback.

        Fig: Block diagram of system

A system boundary is a line that separates the system from the system environment. A change occuring outside the system may affect the performance of the system. Such changes are said to occur in the system environment. Therefore the system environment means anything outside the system boundary that may affect the system.