Mais conteúdo relacionado



  1. 20 Software Engineering: Definition Software Engineering is a collection of techniques, methodologies and tools that helps to produce a high quality software system • with a given budget • before a given deadline • Limited Resources The Software Engineer using this limited amount of resources and integrate several individual and build high quality of Software System.
  2. Software System Failures • Interface Missing • High Budget • Time Exceeds • User Interface Missing • Poor Testing Process • Availability • Modifiability • Extendibility • Security
  3. 1.1 What is Software Engineering or Definition of Software Engineering • Modelling Activity • Problem Solving Activity • Knowledge Acquisition Activity • Rational Management Activity
  4. Modelling Activity • Pattern or Shape • Abstraction Representation • Easy understanding • Avoid Complexity • Answer several Questions Two Mode:- 1.Application Domain Model or Problem Domain Model 2.Solution Domain Model
  5. Problem Solving Activity • Formulate the problem • Analyse the Problem • Search for Solutions • Pick the Solution • Specify the Solution
  6. Knowledge Acquisition Activity • Acquire the Knowledge from Different Sources Ex: Text Books, HR People and Internet
  7. Rational Management Activity • Decision that must improve the Quality of Software System
  8. 1.2 Software Engineering Development Activities • Requirements Engineering • Analysis • System Design or Software Design • Implementation • Testing
  9. Requirements Engineering • Clint and Developer define purpose and scope In terms of Actors and Use Cases • Actor is an External Entity that interact with the System • Use Case is Sequence of events that explain all possible actions b/w Actor and System Ex: Use Case PurchaseOneWayTicket • These two also defined i.e Non-functional Requirements and Pseudo Requirements in RE.
  10. Use Case Name : PurchaseOneWayTicket Participating Actors :Traveller communicates with TicketDistributor Entry Condition :Traveller stand in front of TD Counter located in station. Flow of Events :1.Traveller know source & Destination 2.TD display the price of Ticket 3.Traveler insert money not less than the price of ticket. 4.TD issue Ticket and return any excess of change Exit Condition :Traveller hold Ticket and leaves counter Special Requirement :Transaction is not completed with in one minute TD return all inserted amount. fig1.2 Use Case for PurchaseOneWayTicket
  11. Analysis • Construct the model • Object model for TicketDidtributor Transaction Ticket Zone Balance Rupees Coins inserted valid tracks results Fig.(a)Object Model for TicketDistributor
  12. System Design or Software Design • System is decomposed it into Subsystems based on design goals for each subsystem and select S/W & H/W to implement each subsystem • Specify Global Control flow, Access Control and Boundary Conditions. Fig(b)Subsystem Decomposition for PurchaseOneWayTicket Notification Update CentralDB LocalDB
  13. Implementation • Means the developer write the code, the code first compile then run. Testing • In testing each and every piece is tested then these are integrated and test. Finally the entire system is tested before giving it to the client.
  14. 1.3 The Nature of Software The Mechanical Engg. Build Mechanical System and Electrical Engg. Build Electrical system and the software engg build Software system but building software system is difficult because of following Reasons: • We cannot feel the shape of Software System and Diff. Visualize • Difficult to estimate the time to complete • Difficult to assist its quality • Difficult estimate the cost because in other systems we can estimate the cost by using each item cost multiplied total number of items and number of labour required to build etc. But in Software these is no concept of labour but piece of code is available in Internet, we can change according our specification.
  15. • Software doesn’t “wear out”. Hardware components suffer from the growing effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies, The hardware begins to wear out. When a hardware component wears out, it is replace by a spare part. In Software There are no software spare parts. The Hardware Failure Curve (bathtub curve)and Software Failure curves(idealized curve ).Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected (ideally, without introducing other errors) and the curve flattens as shown.
  16. • The other systems use Software system to automate the Design Process, so that they reduce the Labour and improve the quality. • In reality most of the software systems are undelivered, delivered late, delivered but never been used because of large number of bugs. These are called as software crisis, the Software System does not fall into these crisis. Therefore the Software Engineer must know what is Software Engineering. • The poorly trained software engineer build the software then it is useless. The SE must trained in efficient manner, get domain knowledge and good design knowledge to achieve good quality of Software System.
  17. 1.4 Types of Software Types of Software Classified it into Three: • Custom software • Generic software • Embedded software Custom software : It is developed to meet the specific needs of a particular customer and tends to be of little use to others . Custom software is developed in-house within the same organization that uses it; Eg. Custom software include websites and software for managing the finances of large organizations.
  18. • Generic software : Designed to be sold on the open market and to perform function on general-purpose computers that many people need. • Eg: generic software include word processors, spreadsheets, compilers, web browsers, operating systems, computer games and accounting packages for small businesses. Embedded software: • Runs specific hardware devices which are typically sold on the open market. Such devices include washing machines, microwave ovens and automobiles etc.. Unlike generic software, users cannot usually replace embedded software or upgrade it without also replacing the hardware.
  19. 1.5 Software Quality Almost everybody says they want software to be of ‘high quality The following fig. shows what quality means to each of the stakeholders.
  20. Software Quality depends on 5 Attributes • Usability : The easier it is for users to work with it. There are several aspects of usability, including learnability for novices, efficiency of use for experts, and handling of errors. • Efficiency : The more efficient software is, the less it uses of CPU- time, memory, disk space, network bandwidth and other resources. This is important to customers in order to reduce their costs of running the software. • Reliability : Software is more reliable if it has fewer failures. Reliability depends on number and type of mistakes they make. Designers can improve reliability by ensuring the software is easy to implement and change. • Maintainability : This is the ease with which you can change the software. The more difficult it is to make a change , the lower the maintainability. Software engineers can design highly maintainable software by anticipating future changes and adding flexibility. It reduces the cost for both developers and customers.
  21. • Reusability : A software component is reusable if it can be used in several different systems with little or no modification. High reusability can reduce the long-term costs faced by the development team.
  22. 1.6 Introduction to Object-Orientation • In earlier days Software Systems are build by using Procedural Paradigm(PP) and Procedural Abstraction(PA). • In PA consists of set of functions called from main() function this approach is called as PP, it only suite for simple data if the data is complex then we go for Data Abstraction(DA). • DA can help reduce some of a system’s complexity. Records and structures were the first data abstractions to be introduced. The idea is to group together the pieces of data that describe some entity, so that programmers can manipulate that data as a unit. • Ex: banking system that is written using the procedural paradigm, but using records representing bank accounts. The software has to manage accounts of different types, such as checking, savings and mortgage accounts. Each type of account will have different rules for the computation of fees, interest, etc.
  23. Example of Pseudo cede PP if account is of type checking then do something else if account is of type savings then do something else else do yet another thing end if • Some of the persons have multiple accounts and each A/C has different rates, Therefore it is difficult to implement it in Procedure Paradigm then we go for Object-Oriented Paradigm
  24. Object-Oriented Paradigm • Implement the Real-Time Objects • Problem is viewed as Run-time entities i.e objects, set of objects are combined to form a class. • In the procedural paradigm (shown on the left), the code is organized into procedures that each manipulate different types of data. In the object-oriented paradigm (shown on the right), the code is organized into classes that each contain procedures for manipulating instances of that class.
  25. Banking System implemented Procedure Paradigm(left) and Object-Oriented Paradigm(right)
  26. Features of OOP • Object: Object is run-time entity it can represent real things, it can also called as Instance of a class. Ex: Person, Customer, Bank Account, Chair, Table, Car etc. • Object consists of set of properties or attributes and action to perform , action is nothing but operation. for ex car is object its properties are color, capacity, price ,number of wheels etc. and actions are stop(),start() and run(). Note: In UML Object is Represented by Colon( : ) and Underline(__)
  27. • Class: The class consists of data members and members into a single unit, Once the class is defined we can create any objects belongs to particular class. Employee Name DOB Address Position Credit() Debit() Class name Attributes Actions or Methods Employee Class in Banking System
  28. Difference b/w PP and OOP • PP system is implemented either operations oriented or data oriented but not the both. OOP system is implemented both • In PP the data is moved freely around the system. Ex: Banking System implemented both Credit() AccNumber Balance() Fig(a)PP Debit() Credit() AccNumber Balance() Debit() Fig(b)OOP message message message
  29. Encapsulation • Binding the data and its methods into a single unit • Ex: Customer class in banking system class Customer { private int AccNo=1234; private String name=“ali”; public void display() { System.out.println(“Accno=“+AccNo); System.out.println(“Name=“+name); } } Object Creation and method calling: Customer c1=new Customer(); c1.display();
  30. Data Abstraction • Rep. Essential features without including background details,the class consists of data abstraction technique. • Ex. Car consists of internal parts like engine,radiator,mechanical equipment, electrical equipment etc. the driver to drive a car it requires only driving details not require the knowledge of internal parts. class bank { private int AccNo=1234; private String name=“ali”; private float bal=100000.10; private float profit; private float loan; public void displayToClerk() { System.out.println(“Accno=“+AccNo); System.out.println(“Name=“+name); System.out.println(“Balance=“+bal); } }
  31. Inheritance • Reusability ,using the existing class we derive new class. Several classes have attributes, associations or operations in common, it is best to avoid duplication by creating a separate super class that contains these common aspects. Conversely, if you have a complex class, it may be good to divide its functionality among several specialized subclasses.
  32. Simple Inheritance for Watch watch Time:String Date:String setTime() setDate() readTime() calWatch state:String Calculate(n1:int,n2:int)
  33. class watch { private String time; private String date; public void setTime(); public void setDate(); public void readTime(); } class calWatch extends watch { private String state; public int Calculate(int n1,int n2) { return(n1+n2); } } class test{ public static void main(String args[]) { calWatch c1=new calWatch(); System.out.println(“sum=”+c1.Calculate(10,20); } }
  34. Polymorphism • Ability to take more than one form • Classified it into Compile-Time and Run-Time • The Object is linked for method at Compile Time then Compile-Time or Early Binding this implemented by using method Overloading i.e method name is same and it is used to perform more than one task. Class sample { public int add(int a,int b) { return(a+b); } public int add(int c,int d,int e) { return(c+d+e); } public float add(float f, float g) { return(f+g); } } Class test { public static void main(String args[]) { sample s1=new sample(); System.out.println(s1.add(10,20)); System.out.println(s1.add(10,20,30)); System.out.println(s1.add(10.1,20.2)); } }
  35. Run-Time Polymorphism • We create reference object using this we call different methods at run-time .Simply we say that the Object is linked to the method at run-time then it is called run-time Polymorphism. class one { public void calculate(int x) { system.out.println(“square=“+x*x); } } class two extends one { public void calculate(int x) { system.out.println(“cube=“+x*x*x); } } Class test { public static void main(String args[]) { one obj1=new one(); two obj2=new two(); one ref; ref=obj1; ref.calculate(2); ref =obj2; ref.calculate(2); } }
  36. It refers to the process of defining, documenting and maintaining requirements in the Software engineering Activity to develop high quality of Software System. It is used to identify Functional, Non-functional & Pseudo Req. 2.1 Domain Analysis or Knowledge Domain analysis is the process by which a software engineer learns background information. He or she has to learn sufficient information so as to be able to understand the problem and make good decisions during requirements analysis and other stages of the software engineering process. Examples: Domains such as “ Reservation Systems”, “medical diagnosis”,“ financial ” and Telecommunications, Sales, Accounting etc. The following are benefits if SE as Domain Knowledge: • Faster development. You will be able to communicate with the stakeholders more effectively, hence you will be able to establish requirements more rapidly.. • Better system. Ensure that the solutions you adopt will more effectively solve the customer’s problem. You will make fewer mistakes, and will know which procedures and standards to follow. 2.Requirements Engineering
  37. • Future development. SE include feature requirements and how these requirements are implemented. The Entire domain information is documented then it is called as domain analysis document it consists of following parameters . •Introduction. Name the domain, and give the motivation for performing the analysis. The motivation normally is that you are preparing to solve a particular problem by development or extension of a software system. •Glossary. Describe the meanings of all terms used in the domain that are either not part of everyday language or else have special meanings. •knowledge about the domain. Summarize important facts or rules that are widely known by the domain experts and which would normally be learned as part of their education. Such knowledge includes scientific principles, business processes, analysis techniques, and how any technology works. This is an excellent place to use diagrams. •Customers and users. Describe who will or might buy the software, and in what industrial sectors they operate. Also, describe the other people who work in the domain, even peripherally.
  38. •The Environment. Describe the equipment and systems used. The new system or extensions will have to work in the context of this environment. •Competing Software. Describe what software is available to assist the users and customers, including software that is already in use, and software on the market. Discuss its advantages and disadvantages.
  39. 2.2 The Starting Point for Software Projects • Most of SS are developed from beginning and in some SS modify existing system to add new functionality • SS Developer define all Requirements otherwise Client specify requirements • SS Categorised into four broad categories
  40. 2.3 Defining Problem and Scope The problem statement must be simple easy to understand and must solve the business problem. The system scope must be narrow if it is broad it must be divided it into narrow scope subsystems. OfferedCourses Registration FeePayment Dues ExamScheduale RoomAllotment ConductExams Results Fig(a)Broad Scope Examination System
  41. OfferedCourses Registration FeePayment Dues ExamScheduale RoomAllotment ConductExams Results Fig(b) Narrow Scope Subsystem
  42. 2.3 What is Requirement • A requirement is a statement about what the proposed system will do that all stakeholders agree must be agree must solve the customer’s problem. 2.3.1 Functional requirements : • Functional requirement that directly used in development of a system without this we can’t develop the system, simply we can say that it is essential to implement the system in other words, they describe the services provided for the users and for other systems.
  43. The functional requirements also Specifies as following: • What inputs the system should accept, and under what conditions. This includes data and commands both from the users and from other systems. • What outputs the system should produce, and under what conditions. Outputs can be to the screen or printed. • What data the system should store that other systems might use. • What computations the system should perform. For example, you would describe a sorting process by saying that the result is to be ordered in ascending sequence according to the account number. • The timing and synchronization of the above. Not all systems involve timing and synchronization – this category of functional requirements is of most importance in hard real-time systems that do such things as control hardware devices (e.g. telecommunications systems, systems that control power plants or factories, and systems that run automobiles and airplanes).
  44. Functional Requirements for an embedded software system that allows a us to control a Microwave Oven The system as a whole consists of Functional Req.: • A keypad, with the following buttons that deliver an interrupt to the software when they are pressed: 0 to 9, five power-level buttons (‘hi’, ‘med-hi’, ‘med’, ‘med-low’, ‘low’), three temperature buttons (‘frozen’, ‘refrigerated’, ‘room temperature’) , and five action buttons (‘AUTO-DEFROST’, ‘AUTO-REHEAT’,‘START’, ‘CANCEL’ and ‘TIME OF DAY’). • A door sensor that delivers an interrupt to the software when the door is opened or closed • A digital LCD display on which the system can display output. • A sound generator that the system can use to generate various tones.
  45. The system can be in the following modes • ‘idle’: this is initial state and entered when cooking is complete or when ‘CANCEL’ is pressed. • ‘accepting input’: here system accept the input by using keyboard buttons. • ‘cooking’: this is entered if the door is closed. This is exited when the user opens the door or presses ‘cancel’. • ‘suspended’: this is entered if the user opens the door while cooking or user presses ‘cancel’ button.
  46. The user specifies a valid cooking method in one of the following ways (input): • By pressing ‘AUTO-DEFROST’ followed by an optional sequence of digits indicating the weight in pounds by using keyboard buttons. If the user omits the weight, then the default is 1 pound. • By pressing ‘AUTO-REHEAT’ followed optionally by one of the three temperature buttons. If the user omits the temperature, the default is ‘refrigerated’. • By pressing TIME-OF-DAY a sequence of up to five digits indicating minutes and seconds. The last two digits are the seconds, the previous digits (if any) are the minutes. • Once user select the one of three cooking methods then user press the START button then the will start cooking once it is completed it will issue three beeps then the user press the Power off button.
  47. Non-functional Requirements: • One of the most important things about non-functional requirements is to make them verifiable, non-functional requirements categorized into These groups. Category1:Quality Requirements These requirements constrain the design to meet specified levels of quality. •Response time : The system gives feedback to the user in a certain minimum time •Throughput : In terms of computations or transactions per minute. Resource usage : For systems that use non-trivial amounts of such resources as memory and network bandwidth, you should specify the maximum amount of these resources that the system will consume.
  48. Reliability : Reliability is measured as the average amount of time between failures or the probability of a failure in a given period. It is a good idea to set strong but realistic targets for this. Availability. : Availability measures the amount of time that a server is running and available to respond to users. As with reliability, you should set a target for this. For example, you might specify that a server must be available over 99% of the time. Recovery from failure : They state that if the hardware or software crashes, or the power fails, then the system will be able to recover within a certain amount of time, and with a certain minimal loss of data. For example, the system will allow users to continue their work after a failure with the loss of no more than 20 words of typing or 20 formatting commands.
  49. •Maintainability and Enhancement. In order to ensure that the system can be adapted in the future, you should describe changes that are anticipated for subsequent releases. This constrains design and improves quality without adding explicit new functional requirements. •Reusability. it is desirable in many cases to specify that a certain percentage of the system. •User Interface: Must consists of UI •Security: High level security •Error Handling: must handle errors
  50. Category2:Platform requirements This type of requirement constrains the environment and technology of the system Computing platform. It is normally important to make it clear what hardware and operating system the software must be able to work on. Technology to be used. While it is wise to give the designers as much flexibility as possible in choosing how to implement the system, sometimes constraints must be imposed.
  51. Category3: Process Requirements The final type of requirements constrains the project plan and development methods: Development process (methodology) to be used. In order to ensure quality, some requirements documents specify that certain processes be followed; for example, particular approaches to testing. Cost and delivery date. These are important constraints. However, they are usually not placed in the requirements document, but are found in the contract for the system or are left to a separate project plan document.
  52. 2.4 Techniques for gathering and analyzing requirements : • The following are techniques for gathering and analyzing requirements: • Observation : The first gathering technique, observation, is used to obtain subtle information that stakeholders may not think of telling. We can read documents and discuss extensively with users, but often only the process of observing the users at work will bring to light subtle details the type might otherwise miss. It can consume large amount of time.
  53. • Interviewing : Interviewing is widely use technique. Firstly, plan to have as many members of the software engineering team interview as many stakeholders as possible. Spread out the interviews over time, and allow yourself several hours for each interview. Prepare an extensive list of questions. • Brainstorming : It is an effective way to gather information from a group of people. The general idea is that the group sits around a table and discusses some topic with the goal of generating ideas.
  54. • Prototyping : A prototype is a program that is rapidly implemented and only contains a small part of the anticipated functionality of a complete system. Its purpose is to gather requirements by allowing software engineers to obtain early feedback about their ideas. • Use case analysis : It is a systematic approach to working out what users should be able to do with the software you are developing.
  55. FRIEND SYSTEM :FieldOfficer OpenIncident AllocateResources ReportEmergency :Dispatcher fig(a)Use Case Diagram for FRIEND SYSTEM
  56. Functional Requirements • FieldOfficer: Identified by badge number and he initiate the ReportEmergency • EmergencyForm:It consists of type of emergency, location & description • Dispatcher: he also identified by badge number, he create incident in database and allocate resources • IncidentForm: It consists of following states: Fig: states in Incident
  57. 2.5 Types of Requirements Engineering Documents or Managing Requirements Engineering 1. Eliciting Requiems :KAT(Knowledge Analysis of Task) 2. Specification from Client :JAD(Joint Application Design) 3. Validating Requirements: Usability Testing 4. Documenting Requirements Engineering Activity 1. Eliciting Requiems : KAT Consists of 5 Steps • Identifying Objects • Identifying Procedures • Indentifying Importance • Define Goals and Sub goals • Construct the Model
  58. 2.Specification from Client : JAD Fig:UML Activity diagram for JAD Facilitator
  59. 3.Validating Requirements: Usability Testing • Prototype Test • Usability Test • System Test
  60. 4.Documenting Requirements Engineering Activity