Software Engineering - PPT 1 PDF

PPT 1 Layers (TMPQ) Software – computer instructions that when Tools – offers support for the framework and executed provide desired function and method each software engineering project will performance....

PPT 1 Layers (TMPQ) Software – computer instructions that when Tools – offers support for the framework and executed provide desired function and method each software engineering project will performance. follow. Tools Layer – provides computerized or semi-computerized support for the Characteristics process and method layer. Software is developed or engineered; it is not Computer Aided Software (CASE) – manufactured in the classical sense. Multi usage, tools are integrated in such a way that other tools can use Software doesn’t wear out information. CASE combines software, Most software is custom built, rather than being hardware and software engineering assembled from existing components. database to create software engineering analogous to COMPUTER- AIDED DESIGN (CAD) for hardware. Software Engineering Methods – provide the technical “how to’s” for building software. Fritz Bauer – states that software engineering is Method Layer – provides technical the establishment and use of sound engineering knowledge for developing software. principles in order to obtain economically Process – the glue that holds technology layers software that is reliable and works efficiently on together and enables rational and timely real machines. development of computer software. Process Layer – foundation of software IEEE – states that software engineering is the engineering. application of systematic, disciplined, This layer allows the development of quantifiable approach to the development, software on time. operation and maintenance of software – that Quality Focus – this layer is the fundamental is, the application of engineering to software. layer for software engineering. Test the end product to see if it meets its specifications. Software Engineering Layers Software engineering is a layered technology. Models Any engineering approach must rest on an Waterfall Model – was the first process model to organizational commitment to quality. be introduced. Each phase must be completed before next phase can begin and there is no overlapping in the phases. In Waterfall – the whole process of software development is divided into separate phases.  Measures, Metrics and Indicators Prototyping Model – is an early sample, model, Measure – provides a quantitative indication of or release of a product built to test a concept or the extent, amount, dimensions, capacity, or process. size of some attribute of a product or process. Indicator – is a metric or combination of metrics that provide insight into the software process, Spiral Model – combination of Iterative software project or the project itself. Development Model and Waterfall Model with very high emphasis on risk analysis. Allows incremental refinement through each iteration Process and Project Indicators around the spiral. This model is best used for large projects that involves continuous enhancements. Process Indicator – enable a software engineering organization to gain insight into the efficacy of an existing process. V Model - is SDLC model where execution of processes happens in sequential manner is V- Project Indicator – enable a software manager Shape. It is also known as the Verification and to: Validation Model. assess the status of an ongoing project Every single phase has a directly associated track potential risks testing phase. uncover problem areas adjust work flow evaluate the projects team ability to Iterative Model – method of software control quality software engineering development where product is designed, work products. implemented, and tested incrementally. Key Performance Indicator (KPI) – are relevant PPT 2 performance metrics that are measurable to Software Metrics – refer to a broad range of industry, department or task. measurements for computer software. Process Metrics considered as tactical used by a project manager and software team to adapt project work flow and Metric – is a quantitative measure of the degree technical activities. to which a system, component, or process possesses a given attribute. Twofold intent of Project Metrics 1. Minimize the development schedule.  2. Asses product quality on an ongoing Usability – an attempt to quantify “user basis. friendliness”. Suggested Project Measures (IOR) Inputs- measures the resources required to do Estimating the work. Outputs -measures the deliverables or work Estimate – approximate measure of size, effort, products created during the software duration and staff required to complete a engineering process. project. Results – measures that indicate the Size – measure of how ‘big’ the product is. effectiveness of the deliverables. Effort – number of people hours required to complete an activity. Software Measurement Duration – number of calendar days from start Direct Measures to end of an activity. 1. In software engineering process, it Staff -number of people applied to an activity. includes cost and effort applied. Assumptions – conditions of the project, 2. In product, it includes line of codes environment or personnel considered true for produced, execution speed, memory estimate. size, and defects reported over some set period of time. Risk – Chance of damage, injury or failure resulting from estimate. Metric – Quantitative measure of degree of Indirect Measures – include functionality, possession of attribute. quality, complexity, efficiency and many other “abilities”. Requirement – Assertion that must be true for product to be acceptable to customer. Constraint – requirement reflecting decision Software Quality Measures that cannot change. Correctness – degree to which the software Expectation – assertion must be true for product performs its required function. Can be to achieve complete customer satisfaction. measured in defects per KLOC. Maintainability – ease with which a program can be corrected if an error is encountered. Can be PPT 3 measured using MTTC (mean-time-to change) Requirement Analysis – software engineering Integrity – measures a systems ability to task that bridges the gap between system-level withstand attacks on its security. Can be software allocation and software design. measured in terms of threats and security.  provides the software designer with System Requirements – describe the behavior models that can be translated into data, and information that the solution will manage. architectural, interface, and procedural Structured Charts – shows how an information design. system is organized in a hierarchy of components, called modules. Bridge between system engineering and software design Elements of Analysis Model System Engineering Objectives System Requirement Analysis Describe what the customer requires. System Design Establish a basis for the creation of a software design. Define a set of requirements that can be Five Areas of Effort (PEMSR) validated once the software is built. Problem Recognition Evaluation and Synthesis Data Dictionary – repository containing Modeling descriptions of all data objects consumed or Specification produced by the software. Review Entity Relationship Diagram (ERD) – depicts relationships between data and objects. Configuration Management – set of procedures Data Flow Diagram (DFD) – provides an that track indication of how data are transformed as they Requirements that define a system. move through the system and depicts the Design Modules generated from functions that transform the data flow. requirements State-Transition Diagram – indicates how the Program Code that implements design system behaves as a consequence of Tests that verify the functionality external events. Documents that describe the system. Analysis Process Types of Requirements Data Flow Diagram Business Requirements – higher-level statements of goals, objectives or needs of the Introduced and popularized for enterprise. structured analysis and design in the late 1970s (Gane and Sarson 1979) User Requirements – statements of the needs of Invented by Larry Constantine, the a particular stakeholder or class of original developer of structured design, stakeholders. based on Martin and Estrins “data flow graph” model of computation. Data Flow Diagram – enables analyst to model all of the main requirements for an information Data Flow Rules system in one diagram; inputs and outputs, processes, and data storage. It shows the Process processes that change or transform data. o No process can have only OUTPUTS. If an object has only outputs, then it must be a DFD Conventions source. ▪ Miracle o No process can have only INPUTS, then it must be a sink. ▪ Black Hole Data Store o Data cannot move directly from one data store to another data store. Data must be moved by a process. o Data cannot move directly from Steps in developing DFD an outside source to a data store. Data must be moved by a 1. Make a list of businesses activities and process that receives data from use it to determine various data flows, the source and places the data processes, data stores, and sources. into the data store. 2. Create a context diagram that shows Source/Sink sources and data flows to and from the o Data cannot move directly from system. a source to a sink. It must be 3. Draw Diagram 0 (or Level 1), the next moved by a process if the data level. Show processes but keep them are of any concern to our general. system. Otherwise, the data 4. Create a child diagram for each of the flow is not shown on the DFD. processes in Diagram 0 Data Flow 5. Check for errors and make sure the o It has only one direction of flow labels are meaningful between symbols. It may flow in 6. Develop a physical data flow diagram both directions between a from the logical data flow diagram. process and a data store to 7. Partition the physical data flow diagram show a read before an update. by separating or grouping parts of the Fork diagram in order to facilitate o Means that exactly the same programming and implementation. data GOES from a common location to two or more different processes, data stores, or sources.  Join hierarchical manner, correlating input, o Means that exactly the same processing and output steps. data COME from any two or A completed HIPO package has two more different processes, data parts. A hierarchy chart is used to stores, or sources to a common represent the top-down structure of location. the program. For each module depicted It cannot go directly back to the same on the chart, an IPO chart is used to process it leaves. There must be at least describe the inputs to, outputs from, one other process that handle the data and the process performed by the flow, produces some other data flow, module. and returns the original data flow to the beginning process. Data flow TO a data store means Hipo Package consists of: update. 1. Hierarchy Chart Data flow FROM a data store means 2. IPO Overview Diagram retrieve or use. 3. IPO Detail Diagram Data flow has a noun phrase label. More then one dataflow noun phrase can appear on a single arrow as long as all of PPT 4 the flows on the same arrow move together as one package. Requirements Determination Requirements Determination must be adaptable to the unique needs of accounts and HIPO CHARTS their particular customers or situations. HIPO CHART Requirement – condition that must be met for Stands for Hierarchy Input Process your customers to find your product or service Output acceptable. Was developed by IBM as a tool and Expectation – condition that must be met for documentation technique that your customers to be completely satisfied with attempts to: your product or service. o Provide a structure which functions of a system can be understood Essential Characteristics o State the functions to be accomplished. Requirements Determination is evolutionary o Provide a visual description of and multi-leveled. the input, process and output for each function. OBTAIN, UNDERSTAND, and VALIDATE are Its main purpose is to define applied repeatedly but are not necessarily procedures and operations in a performed sequentially or in any predictable Simulation – animation model of a real-world pattern. activity. N-Fold Structured Walk-through – A set of formal detailed peer reviews of the Obtain requirements Collects the pieces of information from which Usability Lab- Observation of future researchers the customers requirements will be determined. to see how they use a simulation or prototype. Facilitation – group meeting help by neutral session leader. Interviewing – Direct questioning of an individual or small group. Evaluate Prototyping – demonstrating a physical model of Asses how well the RDP and your particular a partial solution to stimulate new ideas. execution of it worked Observation – watch the future users using their Two Perspectives current process. 1. Implementation Evaluation Survey – set of pre-determined questions demonstrates your successful implementation of the RDP and highlights areas for improvement. Understand 2. Process evaluation provide the basis for improvement of the RDP itself. Analyzes and grasps the implications of the customers’ requirements. Modeling – Abstract Representations of data, process, or events. Facilitation – group meeting help by neutral REQUIREMENTS DETERMINATION CAN NEVER session leader. FINISH. A decision to stop may be made when Quality Function Deployment - Matrix everyone agrees, often formally, that the representation of the “voice of the customer” requirements are sufficiently stable and there is not enough value in getting more detail or exploring more possibilities. Therefore, Validate stopping is all about change control and measuring risk. Confirms the mutual understanding of the implications of the requirements with the customer. s Prototyping – demonstrating a physical model of a partial solution to stimulate new ideas.