System Analysis and design

                                           System’s Concept 

Term system is derived from the Greek word ‘Systema’ which means an organized relationship among functioning units or components.
 
 Definition of System:
A system is an orderly grouping of interdependent components linked together according to a plan to achieve a specific objective.
or
 system is an arrangement of element or components that perform a specific task.
or
 A system is a set of interacting or interdependent component parts forming a complex/intricate whole.
Every system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning.

Characteristics of a System

• Organization 

• Interaction 

• Interdependence

• Integration 

• Central Objective 

• Organization-It implies structure and order.

• Interaction-It refers to manner in which each component functions with other components of the system.

• Interdependence-Units/parts are dependent on each other. 

• Integration-The parts of a system work together within the system even though each part performs a unique function. 

• Central Objective-Objective may be real or stated. All the components work together to achieve that particular objective

Some systems share common characteristics, including:

 A system has structure, it contains parts (or components) that are directly or indirectly related to each other;

⦁ A system has behavior, it exhibits processes that fulfill its function or purpose;

⦁ A system has interconnectivity: the parts and processes are connected by structural and/or behavioral relationships;

⦁ A system's structure and behavior may be decomposed via subsystems and sub-processes to elementary parts and process steps;

⦁ A system has behavior that, in relativity to its surroundings, may be categorized as both fast and strong.

*ELEMENTS OF A SYSTEM: AN EXAMPLE

Following are considered as the elements of a system in terms of Information systems: –

⦁ Input

⦁ Output

⦁ Processor

⦁ Control

⦁ Feedback

⦁ Boundary and interface

⦁ Environment

1. INPUT: Input involves capturing and assembling elements that enter the system to be processed. The inputs are said to be fed to the systems in order to get the output. For example, input of a 'computer system' is an input unit consisting of various input devices like a keyboard, mouse, joystick etc.

2. OUTPUT: That element that exists in the system due to the processing of the inputs is known as output. A major objective of a system is to produce output that has value to its user. The output of the system maybe in the form of cash, information, knowledge, reports, documents etc. the system is defined as output is required from it. It is the anticipatory recognition of output that helps in defining the input of the system. For example, output of a 'computer system' is an output unit consisting of various output devices like the screen and the printer etc.

3. PROCESSOR(S): The processor is the element of a system that involves the actual transformation of input into output. It is the operational component of a system. For example, processor of a 'computer system' is central processing unit that further consists of arithmetic and logic unit (ALU), control unit and memory unit etc.

4. CONTROL: The control element guides the system. It is the decision-making sub-system that controls the pattern of activities governing input, processing and output. It also keeps the system within the boundary set. For example, control in a 'computer system' is maintained by the control unit that controls and coordinates various units by means of passing different signals through wires.

5. FEEDBACK: Control in a dynamic system is achieved by feedback. Feedback measures output against a standard input in some form of cybernetic procedure that includes communication and control. The feedback may generally be of three types viz., positive, negative and informational. The positive feedback motivates the system. The negative indicates need of an action. The feedback is a reactive form of control. Outputs from the process of the system are fed back to the control mechanism. The control mechanism then adjusts the control signals to the process on the basis of the data it receives. Feed forward is a protective form of control. For example, in a 'computer system' when logical decisions are taken, the logic unit concludes by comparing the calculated results and the required results.

6. BOUNDARY AND INTERFACE: A system should be defined by its boundaries - the limits that identify its components, processes and interrelationships when it interfaces with another system. For example, in a 'computer system' there is a boundary for the number of bits, the memory size etc. that is responsible for different levels of accuracy on different machines (like 16-bit, 32-bit etc.). The interface in a 'computer system' may be a CUI (Character User Interface) or a GUI (Graphical User Interface).

7. ENVIRONMENT: The environment is the 'super system' within which an organization operates. It excludes input, processes and outputs. It is the source of external elements that impinge on the system. For example, if the results calculated/the output generated by the 'computer system' are to be used for decision-making purposes in the factory, in a business concern, in an organization, in a school, in a college or in a government office then the system is same but its environment is different.

Types of System

• Physical or Abstract System

• Physical – These are tangible entities that may be static or dynamic in operation. For example- parts of a computer center are the desks, chairs etc. that facilitate operation of the computer. They are static and a programmed computer is dynamic.

• Abstract System – These are conceptual or non physical entities. For example- the abstract conceptualization of physical situations. A model is a representation of a real or planned system. A model is used to visualize relationships.

 Deterministic or Probabilistic System 

• Deterministic System – It operates in a predictable manner and the interaction between parts is known with certainty. For example: Two molecules of hydrogen and one molecule of oxygen makes water. 

• Probabilistic System – It shows probable behavior. The exact output is not known. For example: weather forecasting, mail delivery. 

Social, Human Machine, Machine System 

• Social System- It is made up of people. For example: social clubs, societies 

• Human Machine System- When both human and machines are involved to perform a particular a particular task to achieve a target. For example:- Computer. 

• Machine System- Where human interference is neglected. All the tasks are performed by the machine.

 Natural and Manufactured

• Natural System- The system which is natural. For example- Solar system, Seasonal System. 

• Manufactured System- System made by man is called manufactured system. For example- Rockets, Dams, Trains.

Permanent or Temporary System 

• Permanent System- Which persists for long time. For example- policies of business. 

• Temporary System- Made for specified time and after that they are dissolved. For example- setting up DJ system.

 Adaptive and Non Adaptive System 

• Adaptive System- respond to change in the environment in such a way to improve their performance and to survive. For example- Human beings, animals.

 • Non Adaptive System-The system which doesn’t respond to the environment. For example- Machines  

• Open System – It has many interfaces with its environment. It interacts across its boundaries, it receives inputs from and delivers outputs to the outside world. It must adapt to the changing demands of the user.

• Closed System – It is isolated from the environmental influences. A completely closed system is rare. ex

chemical reactions

ER Diagram Representation

Let us now learn how the ER Model is represented by means of an ER diagram. Any object, for example, entities, attributes of an entity, relationship sets, and attributes of relationship sets, can be represented with the help of an ER diagram.

Entity

Entities are represented by means of rectangles. Rectangles are named with the entity set they represent.

Attributes

Attributes are the properties of entities. Attributes are represented by means of ellipses. Every ellipse represents one attribute and is directly connected to its entity (rectangle).

If the attributes are composite, they are further divided in a tree like structure. Every node is then connected to its attribute. That is, composite attributes are represented by ellipses that are connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Relationship

Relationships are represented by diamond-shaped box. Name of the relationship is written inside the diamond-box. All the entities (rectangles) participating in a relationship, are connected to it by a line.

Binary Relationship and Cardinality

A relationship where two entities are participating is called a binary relationship. Cardinality is the number of instance of an entity from a relation that can be associated with the relation.

• One-to-one − When only one instance of an entity is associated with the relationship, it is marked as '1:1'. The following image reflects that only one instance of each entity should be associated with the relationship. It depicts one-to-one relationship.

• One-to-many − When more than one instance of an entity is associated with a relationship, it is marked as '1:N'. The following image reflects that only one instance of entity on the left and more than one instance of an entity on the right can be associated with the relationship. It depicts one-to-many relationship.

• Many-to-one − When more than one instance of entity is associated with the relationship, it is marked as 'N:1'. The following image reflects that more than one instance of an entity on the left and only one instance of an entity on the right can be associated with the relationship. It depicts many-to-one relationship.

• Many-to-many − The following image reflects that more than one instance of an entity on the left and more than one instance of an entity on the right can be associated with the relationship. It depicts many-to-many relationship.

Structure Charts

Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD. It breaks down the entire system into lowest functional modules, describes functions and sub-functions of each module of the system to a greater detail than DFD.

Structure chart represents hierarchical structure of modules. At each layer a specific task is performed.

Module - It represents process or subroutine or task. A control module branches to more than one sub-module. Library Modules are re-usable and invokable from any module.

Pseudo-Code

Pseudo code is written more close to programming language. It may be considered as augmented programming language, full of comments and descriptions.

Pseudo code avoids variable declaration but they are written using some actual programming language’s constructs, like C, Fortran, Pascal etc.

Pseudo code contains more programming details than Structured English. It provides a method to perform the task, as if a computer is executing the code.

Structured Design

Structured design is a conceptualization of problem into several well-organized elements of solution. It is basically concerned with the solution design. Benefit of structured design is, it gives better understanding of how the problem is being solved. Structured design also makes it simpler for designer to concentrate on the problem more accurately.

Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken into several small problems and each small problem is individually solved until the whole problem is solved.

The small pieces of problem are solved by means of solution modules. Structured design emphasis that these modules be well organized in order to achieve precise solution.

These modules are arranged in hierarchy. They communicate with each other. A good structured design always follows some rules for communication among multiple modules, namely -

Cohesion - grouping of all functionally related elements.

Coupling - communication between different modules.

A good structured design has high cohesion and low coupling arrangements

Software Validation

Validation is process of examining whether or not the software satisfies the user requirements. It is carried out at the end of the SDLC. If the software matches requirements for which it was made, it is validated.

• Validation ensures the product under development is as per the user requirements.
• Validation answers the question – "Are we developing the product which attempts all that user needs from this software ?".
• Validation emphasizes on user requirements.

Software Verification

Verification is the process of confirming if the software is meeting the business requirements, and is developed adhering to the proper specifications and methodologies.

• Verification ensures the product being developed is according to design specifications.
• Verification answers the question– "Are we developing this product by firmly following all design specifications ?"
• Verifications concentrates on the design and system specifications.

Target of the test are -

• Errors - These are actual coding mistakes made by developers. In addition, there is a difference in output of software and desired output, is considered as an error.
• Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can cause system to fail.
• Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs when fault exists in the system.

Manual Vs Automated Testing

Testing can either be done manually or using an automated testing tool:

• Manual - This testing is performed without taking help of automated testing tools. The software tester prepares test cases for different sections and levels of the code, executes the tests and reports the result to the manager.
  Manual testing is time and resource consuming. The tester needs to confirm whether or not right test cases are used. Major portion of testing involves manual testing.
• Automated This testing is a testing procedure done with aid of automated testing tools. The limitations with manual testing can be overcome using automated test tools.

A test needs to check if a webpage can be opened in Internet Explorer. This can be easily done with manual testing. But to check if the web-server can take the load of 1 million users, it is quite impossible to test manually.

There are software and hardware tools which helps tester in conducting load testing, stress testing, regression testing.

Testing Approaches

Tests can be conducted based on two approaches –

• Functionality testing
• Implementation testing

When functionality is being tested without taking the actual implementation in concern it is known as black-box testing. The other side is known as white-box testing where not only functionality is tested but the way it is implemented is also analyzed.

Exhaustive tests are the best-desired method for a perfect testing. Every single possible value in the range of the input and output values is tested. It is not possible to test each and every value in real world scenario if the range of values is large.

Black-box testing

It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The tester in this case, has a set of input values and respective desired results. On providing input, if the output matches with the desired results, the program is tested ‘ok’, and problematic otherwise.

In this testing method, the design and structure of the code are not known to the tester, and testing engineers and end users conduct this test on the software.
This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see.

Black-box testing techniques:

• Equivalence class - The input is divided into similar classes. If one element of a class passes the test, it is assumed that all the class is passed.
• Boundary values - The input is divided into higher and lower end values. If these values pass the test, it is assumed that all values in between may pass too.
• Cause-effect graphing - In both previous methods, only one input value at a time is tested. Cause (input) – Effect (output) is a testing technique where combinations of input values are tested in a systematic way.
• Pair-wise Testing - The behavior of software depends on multiple parameters. In pairwise testing, the multiple parameters are tested pair-wise for their different values.
• State-based testing - The system changes state on provision of input. These systems are tested based on their states and input.

White-box testing

White Box Testing(also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is asoftware testing methodin which the internal structure/ design/ implementation of the item being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White box testing is testing beyond the user interface and into the nitty-gritty of a system.

It is conducted to test program and its implementation, in order to improve code efficiency or structure. It is also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to the tester. Programmers of the code conduct this test on the code.

The below are some White-box testing techniques:

• Control-flow testing - The purpose of the control-flow testing to set up test cases which covers all statements and branch conditions. The branch conditions are tested for both being true and false, so that all statements can be covered.
• Data-flow testing - This testing technique emphasis to cover all the data variables included in the program. It tests where the variables were declared and defined and where they were used or changed.

Testing Levels

Testing itself may be defined at various levels of SDLC. The testing process runs parallel to software development. Before jumping on the next stage, a stage is tested, validated and verified.

Testing separately is done just to make sure that there are no hidden bugs or issues left in the software. Software is tested on various levels -

Unit Testing

While coding, the programmer performs some tests on that unit of program to know if it is error free. Testing is performed under white-box testing approach. Unit testing helps developers decide that individual units of the program are working as per requirement and are error free.

Integration Testing

Even if the units of software are working fine individually, there is a need to find out if the units if integrated together would also work without errors. For example, argument passing and data updation etc.

System Testing

The software is compiled as product and then it is tested as a whole. This can be accomplished using one or more of the following tests:

• Functionality testing - Tests all functionalities of the software against the requirement.
• Performance testing - This test proves how efficient the software is. It tests the effectiveness and average time taken by the software to do desired task. Performance testing is done by means of load testing and stress testing where the software is put under high user and data load under various environment conditions.
• Security & Portability - These tests are done when the software is meant to work on various platforms and accessed by number of persons.

Acceptance Testing

When the software is ready to hand over to the customer it has to go through last phase of testing where it is tested for user-interaction and response. This is important because even if the software matches all user requirements and if user does not like the way it appears or works, it may be rejected.

• Alpha testing - The team of developer themselves perform alpha testing by using the system as if it is being used in work environment. They try to find out how user would react to some action in software and how the system should respond to inputs.
• Beta testing - After the software is tested internally, it is handed over to the users to use it under their production environment only for testing purpose. This is not as yet the delivered product. Developers expect that users at this stage will bring minute problems, which were skipped to attend.
• Software project management 

A project is well-defined task, which is a collection of several operations done in order to achieve a goal (for example, software development and delivery). A Project can be characterized as:

• Every project may has a unique and distinct goal.
• Project is not routine activity or day-to-day operations.
• Project comes with a start time and end time.
• Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an organization.
• Project needs adequate resources in terms of time, manpower, finance, material and knowledge-bank.

• • Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software
• • Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software 
• 

software project planning objectives:-

• To introduce software project management and to describe its distinctive characteristics 

• To discuss project planning and the planning process

• To show how graphical schedule representations are used by project management 

• To discuss the notion of risks and the risk management process.

Estimation Techniques

Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.

Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on −

• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks

.

.

.

cocomo model

The constructive cost model was developed by Barry Boehm in the late 1970s^[1] and published in Boehm's 1981 book Software Engineering Economics^[2] as a model for estimating effort, cost, and schedule for software projects. It drew on a study of 63 projects at TRW Aerospace where Boehm was Director of Software Research and Technology. The study examined projects ranging in size from 2,000 to 100,000 lines of code, and programming languages ranging from assembly to PL/I. These projects were based on thewaterfall model of software development which was the prevalent software development process in 1981.

References to this model typically call it COCOMO 81. In 1995 COCOMO II was developed and finally published in 2000 in the book Software Cost Estimation with COCOMO II.^[3]COCOMO II is the successor of COCOMO 81 and is claimed to be better suited for estimating modern software development projects; providing support for more recent software development processes and was tuned using a larger database of 161 projects. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability, and the use of off-the-shelf software components. This article refers to COCOMO 81.

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence of individual project phases.

Basic COCOMO

Basic COCOMO compute software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of source lines of code (SLOC, KLOC).

COCOMO applies to three classes of software projects:

• Organic projects - "small" teams with "good" experience working with "less than rigid" requirements
• Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than rigid requirements
• Embedded projects - developed within a set of "tight" constraints. It is also combination of organic and semi-detached projects.(hardware, software, operational, ...)

The basic COCOMO equations take the form

Effort Applied (E) = a_b(KLOC)^b_b [ man-months ]

Development Time (D) = c_b(Effort Applied)^d_b [months]

People required (P) = Effort Applied / Development Time [count]

where, KLOC is the estimated number of delivered lines (expressed in thousands ) of code for project. The coefficients a_b, b_b, c_b and d_b are given in the following table:

Software project	ab	bb	cb	db
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and so on.

Intermediate COCOMOs

Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers", each with a number of subsidiary attributes:-

• Product attributes
  • Required software reliability
  • Size of application database
  • Complexity of the product
• Hardware attributes
  • Run-time performance constraints
  • Memory constraints
  • Volatility of the virtual machine environment
  • Required turnabout time
• Personnel attributes
  • Analyst capability
  • Software engineering capability
  • Applications experience
  • Virtual machine experience
  • Programming language experience
• Project attributes
  • Use of software tools
  • Application of software engineering methods
  • Required development schedule

Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value). An effort multiplier from the table below applies to the rating. The product of all effort multipliers results in an effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.

Cost Drivers	Ratings
	Very Low	Low	Nominal	High	Very High	Extra High
Product attributes
Required software reliability	0.75	0.88	1.00	1.15	1.40
Size of application database		0.94	1.00	1.08	1.16
Complexity of the product	0.70	0.85	1.00	1.15	1.30	1.65
Hardware attributes
Run-time performance constraints			1.00	1.11	1.30	1.66
Memory constraints			1.00	1.06	1.21	1.56
Volatility of the virtual machine environment		0.87	1.00	1.15	1.30
Required turnabout time		0.87	1.00	1.07	1.15
Personnel attributes
Analyst capability	1.46	1.19	1.00	0.86	0.71
Applications experience	1.29	1.13	1.00	0.91	0.82
Software engineer capability	1.42	1.17	1.00	0.86	0.70
Virtual machine experience	1.21	1.10	1.00	0.90
Programming language experience	1.14	1.07	1.00	0.95
Project attributes
Application of software engineering methods	1.24	1.10	1.00	0.91	0.82
Use of software tools	1.24	1.10	1.00	0.91	0.83
Required development schedule	1.23	1.08	1.00	1.04	1.10

The Intermediate Cocomo formula now takes the form:

E=a_i(KLoC)^(b_i)(EAF)

where E is the effort applied in person-months, KLoC is the estimated number of thousands of delivered lines of code for the project, and EAF is the factor calculated above. The coefficient a_i and the exponent b_i are given in the next table.

Software project	ai	bi
Organic	3.2	1.05
Semi-detached	3.0	1.12
Embedded	2.8	1.20

The Development time D calculation uses E in the same way as in the Basic COCOMO.

Detailed COCOMO

Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process.

The detailed model uses different effort multipliers for each cost driver attribute. These Phase Sensitive effort multipliers are each to determine the amount of effort required to complete each phase. In detailed cocomo,the whole software is divided in different modules and then we apply COCOMO in different modules to estimate effort and then sum the effort

In detailed COCOMO, the effort is calculated as function of program size and a set of cost drivers given according to each phase of software life cycle.

A Detailed project schedule is never static.

The Six phases of detailed COCOMO are:-

• plan and requirement.
• system design.
• detailed design.
• module code and test.
• integration and test.
• Cost Costructive Model

Software Design

Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation.

For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms. The output of this process can directly be used into implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.

Objectives

 To introduce the process of software design 

• To describe the different stages in this design process 

• To show how object-oriented and functional design strategies are complementary 

• To discuss some design quality attributes

Principles of Software Design

Developing design is a cumbersome process as most expansive errors are often introduced in this phase. Moreover, if these errors get unnoticed till later phases, it becomes more difficult to correct them. Therefore, a number of principles are followed while designing the software. These principles act as a framework for the designers to follow a good design practice.

Some of the commonly followed design principles are as following.

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 engineers believe on the phrase: 'do not reinvent the wheel'. Therefore, software components should be designed in such a way that they can be effectively reused to increase the productivity.

9. Designing for testability: A common practice that has been followed is to keep the testing phase separate from the design and implementation phases. That is, first the software is developed (designed and implemented) and then handed over to the testers who subsequently determine whether the software is fit for distribution and subsequent use by the customer. However, it has become apparent that the process of separating testing is seriously flawed, as if any type of design or implementation errors are found after implementation, then the entire or a substantial part of the software requires to be redone. Thus, the test engineers should be involved from the initial stages. For example, they should be involved with analysts to prepare tests for determining whether the user requirements are being met.

10. Prototyping: Prototyping should be used when the requirements are not completely defined in the beginning. The user interacts with the developer to expand and refine the requirements as the development proceeds. Using prototyping, a quick 'mock-up' of the system can be developed. This mock-up can be used as a effective means to give the users a feel of what the system will look like and demonstrate functions that will be included in the developed system. Prototyping also helps in reducing risks of designing software that is not in accordance with the customer's requirements.

Software Design Concepts

Every software process is characterized by basic concepts along with certain practices or methods. Methods represent the manner through which the concepts are applied. As new technology replaces older technology, many changes occur in the methods that are used to apply the concepts for the development of software. However, the fundamental concepts underlining the software design process remain the same, some of which are described here.

Abstraction

Abstraction refers to a powerful design tool, which allows software designers to consider components at an abstract level, while neglecting the implementation details of the components. IEEE defines abstraction as 'a view of a problem that extracts the essential information relevant to a particular purpose and ignores the remainder of the information.' The concept of abstraction can be used in two ways: as a process and as an entity. As a process, it refers to a mechanism of hiding irrelevant details and representing only the essential features of an item so that one can focus on important things at a time. As an entity, it refers to a model or view of an item.

Each step in the software process is accomplished through various levels of abstraction. At the highest level, an outline of the solution to the problem is presented whereas at the lower levels, the solution to the problem is presented in detail. For example, in the requirements analysis phase, a solution to the problem is presented using the language of problem environment and as we proceed through the software process, the abstraction level reduces and at the lowest level, source code of the software is produced.

Architecture

Software architecture refers to the structure of the system, which is composed of various components of a program/ system, the attributes (properties) of those components and the relationship amongst them. The software architecture enables the software engineers to analyze the software design efficiently. In addition, it also helps them in decision-making and handling risks.

Developing a Design Model(Design Methodologies)

To develop a complete specification of design (design model), four design models are needed. These models are listed below.

1. Data design: This specifies the data structures for implementing the software by converting data objects and their relationships identified during the analysis phase. Various studies suggest that design engineering should begin with data design, since this design lays the foundation for all other design models.

2. Architectural design: This specifies the relationship between the structural elements of the software, design patterns, architectural styles, and the factors affecting the ways in which architecture can be implemented.

3. Component-level design: This provides the detailed description of how structural elements of software will actually be implemented.

4. Interface design: This depicts how the software communicates with the system that interoperates with it and with the end-users.

                               

Prototyping

Prototyping is the process of developing prototypes . It is a methodology in its own right and a technique and supplemental methodology to other methodologies. In this case, we will focus on the ways in which prototyping is used as a technique and a supplemental methodology to the systems development life cycle (SDLC).

What is Software Prototyping?

• Prototype is a working model of software with some limited functionality.
• The prototype does not always hold the exact logic used in the actual software application and is an extra effort to be considered under effort estimation.
• Prototyping is used to allow the users evaluate developer proposals and try them out before implementation.
• It also helps understand the requirements which are user specific and may not have been considered by the developer during product design.
• Rapid prototyping is a group of techniques used to quickly fabricate a scale model of a physical part or assembly using three-dimensional computer aided design (CAD) data. Construction of the part or assembly is usually done using 3D printing or "additive layer manufacturing" technology.

• Benefits of prototyping

  Better quality system delivered	Sometimes a developer may not fully understand what the end user is expecting. Prototyping enables any misunderstandings to be identified and sorted out early on in the process.
  Identify problems early on	A working system is available early on in the process. The user can identify possible improvements which can be made before the system is completed.
  End user involvement	The end user feels more involved in the development of the system and will 'buy' into it.
  Fulfill user requirements	A system which has been through prototyping will generally have an improved design quality and will be far closer to what the user needs.
  Cost savings	It is far less expensive to rectify problems with the system in the early stages of development than towards the end of the project.
  Training	The prototype can eventually be used to help train staff while the real system is still being fully developed