SE – Quick Guide

Software Engineering – Quick Guide ”; Previous Next Software Engineering Overview Let us first understand what software engineering stands for. The term is made of two words, software and engineering. Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods. Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product. Definitions IEEE defines software engineering as: (1) The application of a systematic,disciplined,quantifiable approach to the development,operation and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in the above statement. Fritz Bauer, a German computer scientist, defines software engineering as: Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and work efficiently on real machines. Software Evolution The process of developing a software product using software engineering principles and methods is referred to as software evolution. This includes the initial development of software and its maintenance and updates, till desired software product is developed, which satisfies the expected requirements. Evolution starts from the requirement gathering process. After which developers create a prototype of the intended software and show it to the users to get their feedback at the early stage of software product development. The users suggest changes, on which several consecutive updates and maintenance keep on changing too. This process changes to the original software, till the desired software is accomplished. Even after the user has desired software in hand, the advancing technology and the changing requirements force the software product to change accordingly. Re-creating software from scratch and to go one-on-one with requirement is not feasible. The only feasible and economical solution is to update the existing software so that it matches the latest requirements. Software Evolution Laws Lehman has given laws for software evolution. He divided the software into three different categories: S-type (static-type) – This is a software, which works strictly according to defined specifications and solutions. The solution and the method to achieve it, both are immediately understood before coding. The s-type software is least subjected to changes hence this is the simplest of all. For example, calculator program for mathematical computation. P-type (practical-type) – This is a software with a collection of procedures. This is defined by exactly what procedures can do. In this software, the specifications can be described but the solution is not obvious instantly. For example, gaming software. E-type (embedded-type) – This software works closely as the requirement of real-world environment. This software has a high degree of evolution as there are various changes in laws, taxes etc. in the real world situations. For example, Online trading software. E-Type software evolution Lehman has given eight laws for E-Type software evolution – Continuing change – An E-type software system must continue to adapt to the real world changes, else it becomes progressively less useful. Increasing complexity – As an E-type software system evolves, its complexity tends to increase unless work is done to maintain or reduce it. Conservation of familiarity – The familiarity with the software or the knowledge about how it was developed, why was it developed in that particular manner etc. must be retained at any cost, to implement the changes in the system. Continuing growth- In order for an E-type system intended to resolve some business problem, its size of implementing the changes grows according to the lifestyle changes of the business. Reducing quality – An E-type software system declines in quality unless rigorously maintained and adapted to a changing operational environment. Feedback systems- The E-type software systems constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved. Self-regulation – E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal. Organizational stability – The average effective global activity rate in an evolving E-type system is invariant over the lifetime of the product. Software Paradigms Software paradigms refer to the methods and steps, which are taken while designing the software. There are many methods proposed and are in work today, but we need to see where in the software engineering these paradigms stand. These can be combined into various categories, though each of them is contained in one another: Programming paradigm is a subset of Software design paradigm which is further a subset of Software development paradigm. Software Development Paradigm This Paradigm is known as software engineering paradigms where all the engineering concepts pertaining to the development of software are applied. It includes various researches and requirement gathering which helps the software product to build. It consists of – Requirement gathering Software design Programming Software Design Paradigm This paradigm is a part of Software Development and includes – Design Maintenance Programming Programming Paradigm This paradigm is related closely to programming aspect of software development. This includes – Coding Testing Integration Need of Software Engineering The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working. Large software – It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process. Scalability- If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. Cost- As hardware industry has shown its skills and huge manufacturing has lower down he price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted. Dynamic Nature-

Software Testing Overview

Software Testing Overview ”; Previous Next Software Testing is evaluation of the software against requirements gathered from users and system specifications. Testing is conducted at the phase level in software development life cycle or at module level in program code. Software testing comprises of Validation and Verification. 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. 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 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

CASE Tools Overview

Software Case Tools Overview ”; Previous Next CASE stands for Computer Aided Software Engineering. It means, development and maintenance of software projects with help of various automated software tools. CASE Tools CASE tools are set of software application programs, which are used to automate SDLC activities. CASE tools are used by software project managers, analysts and engineers to develop software system. There are number of CASE tools available to simplify various stages of Software Development Life Cycle such as Analysis tools, Design tools, Project management tools, Database Management tools, Documentation tools are to name a few. Use of CASE tools accelerates the development of project to produce desired result and helps to uncover flaws before moving ahead with next stage in software development. Components of CASE Tools CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage: Central Repository – CASE tools require a central repository, which can serve as a source of common, integrated and consistent information. Central repository is a central place of storage where product specifications, requirement documents, related reports and diagrams, other useful information regarding management is stored. Central repository also serves as data dictionary. Upper Case Tools – Upper CASE tools are used in planning, analysis and design stages of SDLC. Lower Case Tools – Lower CASE tools are used in implementation, testing and maintenance. Integrated Case Tools – Integrated CASE tools are helpful in all the stages of SDLC, from Requirement gathering to Testing and documentation. CASE tools can be grouped together if they have similar functionality, process activities and capability of getting integrated with other tools. Scope of Case Tools The scope of CASE tools goes throughout the SDLC. Case Tools Types Now we briefly go through various CASE tools Diagram tools These tools are used to represent system components, data and control flow among various software components and system structure in a graphical form. For example, Flow Chart Maker tool for creating state-of-the-art flowcharts. Process Modeling Tools Process modeling is method to create software process model, which is used to develop the software. Process modeling tools help the managers to choose a process model or modify it as per the requirement of software product. For example, EPF Composer Project Management Tools These tools are used for project planning, cost and effort estimation, project scheduling and resource planning. Managers have to strictly comply project execution with every mentioned step in software project management. Project management tools help in storing and sharing project information in real-time throughout the organization. For example, Creative Pro Office, Trac Project, Basecamp. Documentation Tools Documentation in a software project starts prior to the software process, goes throughout all phases of SDLC and after the completion of the project. Documentation tools generate documents for technical users and end users. Technical users are mostly in-house professionals of the development team who refer to system manual, reference manual, training manual, installation manuals etc. The end user documents describe the functioning and how-to of the system such as user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for documentation. Analysis Tools These tools help to gather requirements, automatically check for any inconsistency, inaccuracy in the diagrams, data redundancies or erroneous omissions. For example, Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total analysis. Design Tools These tools help software designers to design the block structure of the software, which may further be broken down in smaller modules using refinement techniques. These tools provides detailing of each module and interconnections among modules. For example, Animated Software Design Configuration Management Tools An instance of software is released under one version. Configuration Management tools deal with – Version and revision management Baseline configuration management Change control management CASE tools help in this by automatic tracking, version management and release management. For example, Fossil, Git, Accu REV. Change Control Tools These tools are considered as a part of configuration management tools. They deal with changes made to the software after its baseline is fixed or when the software is first released. CASE tools automate change tracking, file management, code management and more. It also helps in enforcing change policy of the organization. Programming Tools These tools consist of programming environments like IDE (Integrated Development Environment), in-built modules library and simulation tools. These tools provide comprehensive aid in building software product and include features for simulation and testing. For example, Cscope to search code in C, Eclipse. Prototyping Tools Software prototype is simulated version of the intended software product. Prototype provides initial look and feel of the product and simulates few aspect of actual product. Prototyping CASE tools essentially come with graphical libraries. They can create hardware independent user interfaces and design. These tools help us to build rapid prototypes based on existing information. In addition, they provide simulation of software prototype. For example, Serena prototype composer, Mockup Builder. Web Development Tools These tools assist in designing web pages with all allied elements like forms, text, script, graphic and so on. Web tools also provide live preview of what is being developed and how will it look after completion. For example, Fontello, Adobe Edge Inspect, Foundation 3, Brackets. Quality Assurance Tools Quality assurance in a software organization is monitoring the engineering process and methods adopted to develop the software product in order to ensure conformance of quality as per organization standards. QA tools consist of configuration and change control tools and software testing tools. For example, SoapTest, AppsWatch, JMeter. Maintenance Tools Software maintenance includes modifications in the software product after it is delivered. Automatic logging and error reporting techniques, automatic error ticket generation and root cause Analysis are few CASE tools, which help software organization in maintenance phase of SDLC. For example, Bugzilla for defect tracking, HP Quality Center. Print Page Previous Next Advertisements ”;

Software Design Complexity

Software Design Complexity ”; Previous Next The term complexity stands for state of events or things, which have multiple interconnected links and highly complicated structures. In software programming, as the design of software is realized, the number of elements and their interconnections gradually emerge to be huge, which becomes too difficult to understand at once. Software design complexity is difficult to assess without using complexity metrics and measures. Let us see three important software complexity measures. Halstead”s Complexity Measures In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software complexity. Halstead’s metrics depends upon the actual implementation of program and its measures, which are computed directly from the operators and operands from source code, in static manner. It allows to evaluate testing time, vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code. According to Halstead, “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operands”. Halstead metrics think a program as sequence of operators and their associated operands. He defines various indicators to check complexity of module. Parameter Meaning n1 Number of unique operators n2 Number of unique operands N1 Number of total occurrence of operators N2 Number of total occurrence of operands When we select source file to view its complexity details in Metric Viewer, the following result is seen in Metric Report: Metric Meaning Mathematical Representation n Vocabulary n1 + n2 N Size N1 + N2 V Volume Length * Log2 Vocabulary D Difficulty (n1/2) * (N1/n2) E Efforts Difficulty * Volume B Errors Volume / 3000 T Testing time Time = Efforts / S, where S=18 seconds. Cyclomatic Complexity Measures Every program encompasses statements to execute in order to perform some task and other decision-making statements that decide, what statements need to be executed. These decision-making constructs change the flow of the program. If we compare two programs of same size, the one with more decision-making statements will be more complex as the control of program jumps frequently. McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity of a given software. It is graph driven model that is based on decision-making constructs of program such as if-else, do-while, repeat-until, switch-case and goto statements. Process to make flow control graph: Break program in smaller blocks, delimited by decision-making constructs. Create nodes representing each of these nodes. Connect nodes as follows: If control can branch from block i to block j Draw an arc From exit node to entry node Draw an arc. To calculate Cyclomatic complexity of a program module, we use the formula – V(G) = e – n + 2 Where e is total number of edges n is total number of nodes The Cyclomatic complexity of the above module is e = 10 n = 8 Cyclomatic Complexity = 10 – 8 + 2 = 4 According to P. Jorgensen, Cyclomatic Complexity of a module should not exceed 10. Function Point It is widely used to measure the size of software. Function Point concentrates on functionality provided by the system. Features and functionality of the system are used to measure the software complexity. Function point counts on five parameters, named as External Input, External Output, Logical Internal Files, External Interface Files, and External Inquiry. To consider the complexity of software each parameter is further categorized as simple, average or complex. Let us see parameters of function point: External Input Every unique input to the system, from outside, is considered as external input. Uniqueness of input is measured, as no two inputs should have same formats. These inputs can either be data or control parameters. Simple – if input count is low and affects less internal files Complex – if input count is high and affects more internal files Average – in-between simple and complex. External Output All output types provided by the system are counted in this category. Output is considered unique if their output format and/or processing are unique. Simple – if output count is low Complex – if output count is high Average – in between simple and complex. Logical Internal Files Every software system maintains internal files in order to maintain its functional information and to function properly. These files hold logical data of the system. This logical data may contain both functional data and control data. Simple – if number of record types are low Complex – if number of record types are high Average – in between simple and complex. External Interface Files Software system may need to share its files with some external software or it may need to pass the file for processing or as parameter to some function. All these files are counted as external interface files. Simple – if number of record types in shared file are low Complex – if number of record types in shared file are high Average – in between simple and complex. External Inquiry An inquiry is a combination of input and output, where user sends some data to inquire about as input and the system responds to the user with the output of inquiry processed. The complexity of a query is more than External Input and External Output. Query is said to be unique if its input and output are unique in terms of format and data. Simple – if query needs low processing and yields small amount of output data Complex – if query needs high process and yields large amount of output data Average – in between simple and complex. Each of these parameters in the system is given weightage according to their class and complexity. The table below mentions the weightage given to each parameter: Parameter Simple Average Complex Inputs 3 4 6 Outputs 4 5 7 Enquiry 3 4 6 Files 7 10 15 Interfaces 5 7 10 The table above yields raw Function Points. These function points are adjusted according to the environment complexity. System is described using fourteen different characteristics: Data communications

Software Requirements

Software Requirements ”; Previous Next The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view. Requirement Engineering The process to gather the software requirements from client, analyze and document them is known as requirement engineering. The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document. Requirement Engineering Process It is a four step process, which includes – Feasibility Study Requirement Gathering Software Requirement Specification Software Requirement Validation Let us see the process briefly – Feasibility study When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop. This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability. The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken. Requirement Gathering If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include. Software Requirement Specification SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team. SRS should come up with following features: User Requirements are expressed in natural language. Technical requirements are expressed in structured language, which is used inside the organization. Design description should be written in Pseudo code. Format of Forms and GUI screen prints. Conditional and mathematical notations for DFDs etc. Software Requirement Validation After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions – If they can be practically implemented If they are valid and as per functionality and domain of software If there are any ambiguities If they are complete If they can be demonstrated Requirement Elicitation Process Requirement elicitation process can be depicted using the folloiwng diagram: Requirements gathering – The developers discuss with the client and end users and know their expectations from the software. Organizing Requirements – The developers prioritize and arrange the requirements in order of importance, urgency and convenience. Negotiation & discussion – If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised. The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably. Documentation – All formal & informal, functional and non-functional requirements are documented and made available for next phase processing. Requirement Elicitation Techniques Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development. There are various ways to discover requirements Interviews Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as: Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly. Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased. Oral interviews Written interviews One-to-one interviews which are held between two persons across the table. Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved. Surveys Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system. Questionnaires A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled. A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended. Task analysis Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected. Domain Analysis Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements. Brainstorming An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. 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

Software Engineering Overview

Software Engineering Overview ”; Previous Next Let us first understand what software engineering stands for. The term is made of two words, software and engineering. Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods. Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product. Definitions IEEE defines software engineering as: (1) The application of a systematic,disciplined,quantifiable approach to the development,operation and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in the above statement. Fritz Bauer, a German computer scientist, defines software engineering as: Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and work efficiently on real machines. Software Evolution The process of developing a software product using software engineering principles and methods is referred to as software evolution. This includes the initial development of software and its maintenance and updates, till desired software product is developed, which satisfies the expected requirements. Evolution starts from the requirement gathering process. After which developers create a prototype of the intended software and show it to the users to get their feedback at the early stage of software product development. The users suggest changes, on which several consecutive updates and maintenance keep on changing too. This process changes to the original software, till the desired software is accomplished. Even after the user has desired software in hand, the advancing technology and the changing requirements force the software product to change accordingly. Re-creating software from scratch and to go one-on-one with requirement is not feasible. The only feasible and economical solution is to update the existing software so that it matches the latest requirements. Software Evolution Laws Lehman has given laws for software evolution. He divided the software into three different categories: S-type (static-type) – This is a software, which works strictly according to defined specifications and solutions. The solution and the method to achieve it, both are immediately understood before coding. The s-type software is least subjected to changes hence this is the simplest of all. For example, calculator program for mathematical computation. P-type (practical-type) – This is a software with a collection of procedures. This is defined by exactly what procedures can do. In this software, the specifications can be described but the solution is not obvious instantly. For example, gaming software. E-type (embedded-type) – This software works closely as the requirement of real-world environment. This software has a high degree of evolution as there are various changes in laws, taxes etc. in the real world situations. For example, Online trading software. E-Type software evolution Lehman has given eight laws for E-Type software evolution – Continuing change – An E-type software system must continue to adapt to the real world changes, else it becomes progressively less useful. Increasing complexity – As an E-type software system evolves, its complexity tends to increase unless work is done to maintain or reduce it. Conservation of familiarity – The familiarity with the software or the knowledge about how it was developed, why was it developed in that particular manner etc. must be retained at any cost, to implement the changes in the system. Continuing growth- In order for an E-type system intended to resolve some business problem, its size of implementing the changes grows according to the lifestyle changes of the business. Reducing quality – An E-type software system declines in quality unless rigorously maintained and adapted to a changing operational environment. Feedback systems- The E-type software systems constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved. Self-regulation – E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal. Organizational stability – The average effective global activity rate in an evolving E-type system is invariant over the lifetime of the product. Software Paradigms Software paradigms refer to the methods and steps, which are taken while designing the software. There are many methods proposed and are in work today, but we need to see where in the software engineering these paradigms stand. These can be combined into various categories, though each of them is contained in one another: Programming paradigm is a subset of Software design paradigm which is further a subset of Software development paradigm. Software Development Paradigm This Paradigm is known as software engineering paradigms where all the engineering concepts pertaining to the development of software are applied. It includes various researches and requirement gathering which helps the software product to build. It consists of – Requirement gathering Software design Programming Software Design Paradigm This paradigm is a part of Software Development and includes – Design Maintenance Programming Programming Paradigm This paradigm is related closely to programming aspect of software development. This includes – Coding Testing Integration Need of Software Engineering The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working. Large software – It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process. Scalability- If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. Cost- As hardware industry has shown its skills and huge manufacturing has lower down he price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted. Dynamic Nature- The always growing and adapting

Software Design Strategies

Software Design Strategies ”; Previous Next Software design is a process to conceptualize the software requirements into software implementation. Software design takes the user requirements as challenges and tries to find optimum solution. While the software is being conceptualized, a plan is chalked out to find the best possible design for implementing the intended solution. There are multiple variants of software design. Let us study them briefly: 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. Function Oriented Design In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions are capable of performing significant task in the system. The system is considered as top view of all functions. Function oriented design inherits some properties of structured design where divide and conquer methodology is used. This design mechanism divides the whole system into smaller functions, which provides means of abstraction by concealing the information and their operation.. These functional modules can share information among themselves by means of information passing and using information available globally. Another characteristic of functions is that when a program calls a function, the function changes the state of the program, which sometimes is not acceptable by other modules. Function oriented design works well where the system state does not matter and program/functions work on input rather than on a state. Design Process The whole system is seen as how data flows in the system by means of data flow diagram. DFD depicts how functions changes data and state of entire system. The entire system is logically broken down into smaller units known as functions on the basis of their operation in the system. Each function is then described at large. Object Oriented Design Object oriented design works around the entities and their characteristics instead of functions involved in the software system. This design strategies focuses on entities and its characteristics. The whole concept of software solution revolves around the engaged entities. Let us see the important concepts of Object Oriented Design: Objects – All entities involved in the solution design are known as objects. For example, person, banks, company and customers are treated as objects. Every entity has some attributes associated to it and has some methods to perform on the attributes. Classes – A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the functionality of the object. In the solution design, attributes are stored as variables and functionalities are defined by means of methods or procedures. Encapsulation – In OOD, the attributes (data variables) and methods (operation on the data) are bundled together is called encapsulation. Encapsulation not only bundles important information of an object together, but also restricts access of the data and methods from the outside world. This is called information hiding. Inheritance – OOD allows similar classes to stack up in hierarchical manner where the lower or sub-classes can import, implement and re-use allowed variables and methods from their immediate super classes. This property of OOD is known as inheritance. This makes it easier to define specific class and to create generalized classes from specific ones. Polymorphism – OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned same name. This is called polymorphism, which allows a single interface performing tasks for different types. Depending upon how the function is invoked, respective portion of the code gets executed. Design Process Software design process can be perceived as series of well-defined steps. Though it varies according to design approach (function oriented or object oriented, yet It may have the following steps involved: A solution design is created from requirement or previous used system and/or system sequence diagram. Objects are identified and grouped into classes on behalf of similarity in attribute characteristics. Class hierarchy and relation among them is defined. Application framework is defined. Software Design Approaches Here are two generic approaches for software designing: Top Down Design We know that a system is composed of more than one sub-systems and it contains a number of components. Further, these sub-systems and components may have their on set of sub-system and components and creates hierarchical structure in the system. Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics. Each sub-system or component is then treated as a system and decomposed further. This process keeps on running until the lowest level of system in the top-down hierarchy is achieved. Top-down design starts with a generalized model of system and keeps on defining the more specific part of it. When all components are composed the whole system comes into existence. Top-down design is more suitable when the software solution needs to be designed from scratch and specific details are unknown. Bottom-up Design The bottom up design model starts with most specific and basic components. It proceeds with composing higher level of components by using basic or

Software Project Management

Software Project Management ”; Previous Next The job pattern of an IT company engaged in software development can be seen split in two parts: Software Creation 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. Software Project A Software Project is the complete procedure of software development from requirement gathering to testing and maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product. Need of software project management Software is said to be an intangible product. Software development is a kind of all new stream in world business and there’s very little experience in building software products. Most software products are tailor made to fit client’s requirements. The most important is that the underlying technology changes and advances so frequently and rapidly that experience of one product may not be applied to the other one. All such business and environmental constraints bring risk in software development hence it is essential to manage software projects efficiently. The image above shows triple constraints for software projects. It is an essential part of software organization to deliver quality product, keeping the cost within client’s budget constrain and deliver the project as per scheduled. There are several factors, both internal and external, which may impact this triple constrain triangle. Any of three factor can severely impact the other two. Therefore, software project management is essential to incorporate user requirements along with budget and time constraints. Software Project Manager A software project manager is a person who undertakes the responsibility of executing the software project. Software project manager is thoroughly aware of all the phases of SDLC that the software would go through. Project manager may never directly involve in producing the end product but he controls and manages the activities involved in production. A project manager closely monitors the development process, prepares and executes various plans, arranges necessary and adequate resources, maintains communication among all team members in order to address issues of cost, budget, resources, time, quality and customer satisfaction. Let us see few responsibilities that a project manager shoulders – Managing People Act as project leader Liaison with stakeholders Managing human resources Setting up reporting hierarchy etc. Managing Project Defining and setting up project scope Managing project management activities Monitoring progress and performance Risk analysis at every phase Take necessary step to avoid or come out of problems Act as project spokesperson Software Management Activities Software project management comprises of a number of activities, which contains planning of project, deciding scope of software product, estimation of cost in various terms, scheduling of tasks and events, and resource management. Project management activities may include: Project Planning Scope Management Project Estimation Project Planning Software project planning is task, which is performed before the production of software actually starts. It is there for the software production but involves no concrete activity that has any direction connection with software production; rather it is a set of multiple processes, which facilitates software production. Project planning may include the following: Scope Management It defines the scope of project; this includes all the activities, process need to be done in order to make a deliverable software product. Scope management is essential because it creates boundaries of the project by clearly defining what would be done in the project and what would not be done. This makes project to contain limited and quantifiable tasks, which can easily be documented and in turn avoids cost and time overrun. During Project Scope management, it is necessary to – Define the scope Decide its verification and control Divide the project into various smaller parts for ease of management. Verify the scope Control the scope by incorporating changes to the scope Project Estimation For an effective management accurate estimation of various measures is a must. With correct estimation managers can manage and control the project more efficiently and effectively. Project estimation may involve the following: Software size estimation Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by calculating number of function points in the software. Lines of code depend upon coding practices and Function points vary according to the user or software requirement. Effort estimation The managers estimate efforts in terms of personnel requirement and man-hour required to produce the software. For effort estimation software size should be known. This can either be derived by managers’ experience, organization’s historical data or software size can be converted into efforts by using some standard formulae. Time estimation Once size and efforts are estimated, the time required to produce the software can be estimated. Efforts required is segregated into sub categories as per the requirement specifications and interdependency of various components of software. Software tasks are divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The tasks are scheduled on day-to-day basis or in calendar months. The sum of time required to complete all tasks in hours or days is the total time invested to complete the project. Cost estimation This might be considered as the most difficult of all because it depends on more elements than any of the previous ones. For estimating project cost, it is required to consider – Size of software Software quality Hardware Additional software or tools, licenses etc. Skilled personnel with task-specific skills Travel involved Communication Training and support Project Estimation Techniques We discussed various parameters involving project estimation such as size, effort, time and cost. Project manager can estimate the listed factors using two

Software Engineering Home

Software Engineering Tutorial PDF Version Quick Guide Resources Job Search Discussion Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product. Software project management has wider scope than software engineering process as it involves communication, pre and post delivery support etc. This tutorial should provide you basic understanding of software product, software design and development process, software project management and design complexities etc. At the end of the tutorial you should be equipped with well understanding of software engineering concepts. Audience This tutorial is designed for the readers pursuing education in software development domain, Software Testing aspirants and all enthusiastic readers. Prerequisites This tutorial is designed and developed for absolute beginners. Though, awareness about software systems, software development process and computer fundamentals would be beneficial. Print Page Previous Next Advertisements ”;

SE – Useful Resources

Software Engineering – Useful Resources ”; Previous Next The following resources contain additional information on Software Engineering. Please use them to get more in-depth knowledge on this topic. Useful Links on Software Engineering Software Engineering − Get the history and other details How to Become a Software Engineer − Have a look at the steps of becoming a software engineer Useful Books on Software Engineering To enlist your site on this page, please drop an email to [email protected] Print Page Previous Next Advertisements ”;