Various Concepts Used In Software Engineering

Throw Away Prototyping :-

it is a small part of the system is developed and then given to the end user to try out and evaluate. The user provides feedback which can quickly be incorporated into the development of the main system.

The prototype is then discarded or thrown away. This is very different to the evolutionary approach.

The objective of throw-away prototyping is to ensure that the system requirements are validated and that they are clearly understood.

The throw-away prototype is NOT considered part of the final system. It is simply there to aid understanding and reduce the risk of poorly defined requirements. The full system is being developed alongside the prototypes and incorporates the changes needed.

The advantage of this approach is the speed with which the prototype is put together. It also focuses the user on only one aspect of the system so keeping their feedback precise.

One disadvantage with throw-away prototyping is that developers may be pressurised by the users to deliver it as a final system! Another issue is that all the man-hours of putting together the throw away prototypes are lost unlike the evolutionary approach. But the benefits may outweigh the disadvantages.

Which approach to use (evolutionary or throw-away) will depend on the nature of the system being developed.

Modularity in software engineering :-

Modularity refers to breaking down software into different parts. These parts have differerent names depending on your programming paridigm (for example, we talk about modules in imperative programming and objects in object oriented programming). Software modularity indicates that the number of application modules are capable of serving a specified business domain.

Modularity is successful because developers use prewritten code, which saves resources. Overall, modularity provides greater software development manageability.

Software engineering modularity allows typical applications to be divided into modules, as well as integration with similar modules, which helps developers use prewritten code. Modules are divided based on functionality, and programmers are not involved with the functionalities of other modules. Thus, new functionalities may be easily programmed in separate modules.

Code Review in software engineering :- 

Code review is systematic examination (often as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.Code reviews can often find and remove common vulnerabilities such as format string exploits, race conditions, memory leaks and buffer overflows, thereby improving software security. Online software repositories based on Subversion (with Redmine or Trac), Mercurial, Git or others allow groups of individuals to collaboratively review code. Additionally, specific tools for collaborative code review can facilitate the code review process.

Dynamic Analysis vs. Static Analysis:-

Dynamic analysis is the testing and evaluation of an application during runtime.

Static analysis is the testing and evaluation of an application by examining the code without executing the application.

Many software defects that cause memory and threading errors can be detected both dynamically and statically. The two approaches are complementary because no single approach can find every error.

The primary advantage of dynamic analysis: It reveals subtle defects or vulnerabilities whose cause is too complex to be discovered by static analysis. Dynamic analysis can play a role in security assurance, but its primary goal is finding and debugging errors.

The primary advantage of static analysis: It examines all possible execution paths and variable values, not just those invoked during execution. Thus static analysis can reveal errors that may not manifest themselves until weeks, months or years after release. This aspect of static analysis is especially valuable in security assurance, because security attacks often exercise an application in unforeseen and untested ways.

Gantt chart :-

A Gantt chart, commonly used in project management, is one of the most popular and useful ways of showing activities (tasks or events) displayed against time. On the left of the chart is a list of the activities and along the top is a suitable time scale. Each activity is represented by a bar; the position and length of the bar reflects the start date, duration and end date of the activity. This allows you to see at a glance:

• What the various activities are
• When each activity begins and ends
• How long each activity is scheduled to last
• Where activities overlap with other activities, and by how much
• The start and end date of the whole project

To summarize, a Gantt chart shows you what has to be done (the activities) and when (the schedule).

Non-functional requirement:-

Non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.

Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do <requirement>", an individual action of part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model. In contrast, non-functional requirements are in the form of "system shall be <requirement>", an overall property of the system as a whole or of a particular aspect and not a specific function. The systems' overall properties commonly mark the difference between whether the development project has succeeded or failed.
Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals", "quality of service requirements" and "non-behavioral requirements".Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities, that is non-functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system