Home

Software Engineering

1. B Processor and memory upgrade Hardware cost increase Experience decrease E New de velopment system Hardware cost increase Experience decrease C Memory upgrade only Hardware cost increase F Staff with hardware experience D More experienced staff 116 Management Options Costs Option RELY STOR TIME TOOIS LTEX Totaleffort Software cost Hardware Total cost cost A 139 1 06 Ll 0 86 1 63 949393 100000 1049393 B 139 1 1 1 12 1 22 88 1313550 120000 1402025 Cc 139 1 1 11 0 86 1 60 895653 105000 1000653 D 1 39 1 06 1 11 0 86 0 84 34 769008 100000 897490 E 139 1 1 0 72 1 22 56 844425 220000 1044159 F 139 1 1 1 12 0 84 57 851180 120000 1002706 Option Choice e Option D use more experienced staff appears to be the best alternative However it has a high associated risk as experienced staff may be difficult to find e Option C upgrade memory has a lower cost saving but very low risk e Overall the model reveals the importance of staff experience in software development Project Duration and Staffing e As well as effort estimation managers must estimate the calendar time required to complete a project and when staff will be required e Calendar time can be estimated using a COCO MO 2 formula TDEV 3 PM 0 33 0 2 B 1 01 PM is the effort computation and B is the exponent computed as discussed above B is 1 for the early prototyping model This computation predicts
2. Requirement Interactions e Competing conflicting requirements are common with complex systems e Spacecraft system example To minimize weight the number of chips in the unit should be minimized To minimize power consumption low power chips should be used But using low power chips means that more chips have to be used Which is the most critical requirement e For this reason preferred points in the solution space should be identified Domain Requirements e Derived from the application domain rather than user needs e May be new functional requirements or constraints on existing requirements e If domain requirements are not satisfied the system may be unworkable Library System Domain Requirements e There shall be a standard user interface to all databases which shall be based on the Z39 50 standard e Because of copyright restrictions some documents must be deleted immediately on arrival Depending on the user s requirements these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer Train Protection System Domain Requirement e The deceleration of the train shall be computed as Dtrain Dcontrol Dgradient where D gradient is 9 81m s2 compensated gradient alpha and where the values of 9 81m s2 alpha are known for different types of train Domain Requirements Problems e Understandability requirements are expres
3. To explain why different techniques should be used for software estimation To describe the COCOMO 2 algorithmic cost estimation model Topics Covered Productivity e Estimation techniques e Algorithmic cost modelling e Project duration and staffing Fundamental Estimation Questions How much effort is required to complete an activity e How much calendar time is needed to complete an activity What is the total cost of an activity e Project estimation and scheduling and interleaved management activities Softw are Cost Components Hardware and software costs Travel and training costs e Effort costs the dominant factor in most projects Salaries of engineers involved in the project Social and insurance costs e Effort costs must take overheads into account Costs of building heating lighting Costs of networking and communications Costs of shared facilities e g library staff restaurant etc Costing and Pricing e Estimates are made to discover the cost to the developer of producing a software system e There is not a simple relationship between the development cost and the price charged to the customer e Broader organisational economic political and business considerations influence the price charged Softw are Pricing Factors Description A development organisation may quote a low price cause it wishes to mov nto a new segment of the software market Accepting a low profit
4. Short term memory Working memory Long term memory Lar ge capacity slow access Short term Memory e Fast access limited capacity e 5 7 locations e Holds chunks of information where the size of a chunk may vary depending on its familiarity e Fast decay time Working Memory e Larger capacity longer access time e Memory area used to integrate information from short term memory and long term memory e Relatively fast decay time Long term Memory e Slow access very large capacity e Unreliable retrieval mechanism Slow but finite decay time information needs reinforced e Relatively high threshold work has to be done to get information into long term memory Information Transfer e Problem solving usually requires transfer between short term memory and working memory e Information may be lost or corrupted during this transfer Information processing occurs in the transfer from short term to long term memory 104 Cognitive Chunking Loop process entire array Loop process unsorted part of array Know ledge Modelling e Semantic knowledge knowledge of concepts such as the operation of assignment concept of parameter passing etc e Syntactic knowledge knowledge of details of a representation e g an Ada while loop e Semantic knowledge seems to be stored in a structured representation independent way Syntactic Semantic Knowledge Syntactic knowledge Semantic knowledge
5. The common core of the application family is reused each time a new application is required e Each specific application is specialized in some way Application Family Specialization e Platform specialization different versions of the application are developed for different platforms Configuration specialization different versions of the application are created to handle different peripheral devices Functional specialization different versions of the application are created for customers with different requirements Family Member Development requirements J system Elicit stakeholder requirements 4 Use existing family member as prototype Design Patterns Chris Alexander Mid 70 s A way of reusing accumulated knowledge and wisdom about a problem and its solution Choose closest gt fit family member Delivernew family member f e A design pattern is a description of some problem and the essence of its solution e Should be sufficiently abstract to be reusable in different contexts e Often utilize OO characteristics such as inheritance and polymorphism Pattern Elements Gamma 95 e Name a meaningful pattern identifier e Problem description Solution description a template for a design solution that can be instantiated in different operational contexts often illustrated graphically e Consequences the results and trade offs of applying t
6. Defect testing e Integration testing Object oriented testing Testing workbenches The Testing Process e Component testing Testing of individual program components Usually the responsibility of the component developer except sometimes for critical systems Tests are derived from the developer s experience e Integration testing Testing of groups of components integrated to create a system or sub system The responsibility of an independent testing team Tests are based on a system specification Integration testing Independent testing team Testing Phases Component testing Software developer Defect Testing e Testing programs to establish the presence of system defects The goal of defect testing is to discover defects in programs e A successful defect test is a test which causes a program to behave in an anomalous way Tests show the presence not the absence of defects Testing Priorities Only exhaustive testing can show a program is free from defects However exhaustive testing is impossible e Tests should exercise a system s capabilities rather than its components e Testing old capabilities is more important than testing new capabilities Testing typical situations is more important than boundary value cases Test Data and Test Cases Test data Inputs which have been devised to test the system Test cases Inputs to test the system and the predicted outputs from these inputs i
7. The requirements engineering process includes a feasibility study elicitation and analysis specification and validation e Requirements analysis is an iterative process involving domain understanding requirements collection classification structuring prioritization and validation e Systems have multiple stakeholders with different viewpoints and requirements e Social and organization factors influence system requirements Requirements validation is concerned with checks for validity consistency complete ness realism and verifiability e Business organizational and technical changes inevitably lead to changing requirements Requirements management involves careful planning and a change management process 32 Activity Suggest who might be stakeholders in a university student records system Explain why it is almost inevitable that the requirements of different stakeholders will conflict in some ways Activity A software system is to be developed to automate a library catalogue This system will contain information about all the books in a library and will be usable by library staff and by book borrows and reasons the system should support catalogue browsing querying and should provide facilities allowing users to send messages to library staff reserving a book which is on loan Identify the principal viewpoints which might be taken into account in the specification of this system and show their relation
8. What parts of the system are to maintain most likely to be affected by chan ge requests Predicting maintainability Predicting maintenance costs Predicting system changes How many change requests can be expected maintaining this s over the next y Change Prediction e Predicting the number of changes requires and understanding of the relationships between a system and its environment Tightly coupled systems require changes whenever the environment is changed Factors influencing this relationship are Number and complexity of system interfaces Number of inherently volatile system requirements The business processes where the system is used Complexity Metrics e Predictions of maintainability can be made by assessing the complexity of system components e Studies have shown that most maintenance effort is spent on a relatively small number of system components e Complexity depends on Complexity of control structures Complexity of data structures Procedure and module size Process Metrics e Process measurements may be used to assess maintainability Number of requests for corrective maintenance Average time required for impact analysis Average time taken to implement a change request Number of outstanding change requests e If any or all of these is increasing this may indicate a decline in maintainability Architectural Evolution e There is a need to convert many legacy system
9. do in each state Can be complemented by tables describing the states and the stimuli Microwave Oven Operation Semantic Data Models Used to describe the logical structure of data processed by the system e Entity relation attribute model sets out the entities in the system the relationships between these entities and the entity attributes e Widely used in database design Can readily be implemented using relational databases No specific notation provided in the UML but objects and associations can be used Softw are Design Semantic M odel name description C date M date has nodes has links has labels has lab els Data Dictionaries Data dictionaries are lists of all of the names used in the system models Descriptions of the entities relationships and attributes are also included e Advantages Support name management and avoid duplication Store of organisational knowledge linking analysis design and implementation e Many CASE workbenches support data dictionaries Data Dictionary Entries Name Description Type Date 1 N relation between entities of type has labels Node or Link and entities of type Relation 5 10 1998 Label Holds structured or unstructured Label information about nodes or links Entity 8 12 1998 Labels are represented by an icon which can be a transparent box and associated text A 1 1 relation between design Link entities represente
10. e A drinks vending machine which can dispense coffee with and without milk and sugar The user deposits a coin and makes his or her selection by pressing a button on the machine This causes a cup with powdered coffee to be output The user places this cup under a tap presses another button and hot eater is dispensed Activity Discuss the strengths and weaknesses of Java as a program ming language for real time systems 79 ONIMSANIDONA AYVMLAIOS ONIMAANIDON A AYVMLIOS Activity You are asked to work on a real time development project for a military application but have no previous experience of projects in that domain Discuss what you as a professional software engineer should do before starting work on the project Notes 80 LESSON 23 DESIGN WITH REUSE Objectives To explain the benefits and some potential problems with software reuse To describe different types of reusable elements and processes for reuse To introduce application families as a route to reuse To describe design patterns as high level abstractions that promote reuse Topics Covered Component based development Application families Design patterns Reuse based Softw are Engineering In most engineering disciplines systems are routinely designed by composing elements that have been used in other systems This has not been true in SE but to reduce risks and accelerate development it is now recognized that we need to
11. e May make use of simple to use terminals such as touch screens Advantages of Menu Systems e Users need not remember command names as they are always presented with a list of valid commands e Typing effort is minimal e User errors are trapped by the interface e Context dependent help can be provided The user s context is indicated by the current menu selection Problems With Menu Systems Actions which involve logical conjunction and or disjunction or are awkward to represent e Menu systems are best suited to presenting a small number of choices If there are many choices some menu structuring facility must be used e Experienced users find menus slower than command language Form based Interface NE W BOOK Publication 1g Number of Edition copies Lo status purchase Lr purchase status C C Command Interfaces User types commands to give instructions to the system e g UNIX e May be implemented using cheap terminals e Easy to process using compiler techniques Commands of arbitrary complexity can be created by command combination e Concise interfaces requiring minimal typing can be created Problems With Command Interfaces e Users have to learn and remember a command language Command interfaces are therefore unsuitable for occasional users e Users make errors in command An error detection and recovery system is required 86 e System interaction is through a ke
12. Knowledge Acquisition e Semantic knowledge through experience and active learning the ah factor e Syntactic knowledge acquired by memorisation New syntactic knowledge can interfere with existing syntactic knowledge Problems arise for experienced programmers in mixing up syntax of different programming languages Semantic Knowledge Computing concepts notion of a writable store iteration concept of an object etc Task concepts principally algorithmic how to tackle a particular task Software development ability is the ability to integrate new knowledge with existing computer and task knowledge and hence derive creative problem solutions Thus problem solving is language independent Problem Solving e Requires the integration of different types of knowledge computer task domain organisation Development of a semantic model of the solution and testing of this model against the problem e Representation of this model in an appropriate notation or programming language Partial solutions Solution New knowledge Existing knowledge Working memory Long term memory Motivation e An important role of a manager is to motivate the people working on a project e Motivation is a complex issue but it appears that their are different types of motivation based on Basic needs e g food sleep etc Personal needs e g respect self esteem Social needs e
13. e However there are a number of generic activities common to most processes Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility Study e Determines whether or not the proposed undertaking is worthwhile e Aims to answer three basic questions Would the system contribute to overall organizational objec tives Could the system be engineered using current technology and within budget Could the system be integrated with other systems already in use Feasibility Study Issues e How would the organization cope if the system weren t implemented e What are the current process problems and how would the system help with these e What will the integration problems be e Is new technology needed New skills e What must be supported by the system and what need not be supported Elicitation and Analysis e Involves working with customers to learn about the application domain the services needed and the system s operational constraints e May also involve end users managers maintenance personnel domain experts trade unions etc That is any stakeholders Problems of Elicitation and Analysis e Getting all and only the right people involved e Stakeholders often don t know what they really want T I know when I see it e Stakeholders express requirements in their own terms e Stakeholders may have conflicting requirements e
14. Lesson 23 Design with Reuse 8 j 9 0 Software Testing 0 4 8 1 85 3 7 1 04 Managing People 1 1 Software Engineering Lesson No Topic Page No Lesson 30 Managing People Lesson 32 Software Cost Estimation Lesson 33 Quality Management 6 8 Lesson 31 Software Cost Estimation 2 j 5 9 10 i 11 i 11 120 132 13 i 144 LESSON 1 INTRODUCTION Getting Started With Software Engineering Objectives e To introduce software engineering and to explain its importance e To set out the answers to key questions about software engineering e To introduce ethical and professional issues and to explain why they are of concern to software engineers Topics Covered e FAQs about software engineering e Professional and ethical responsibility Software Engineering The economies of ALL developed nations are dependent on software More and more systems are software controlled Software engineering is concerned with theories methods and tools for professional software development Software engineering expenditure represents a significant fraction of GNP in all developed countries Software Costs Software costs often dominate system costs The costs of software on a PC are often greater than the hardware cost Software costs more to maintain than it does to develop For systems with a long life maintenance costs may be several times development costs Software engineering is conce
15. adopt design processes based on systematic reuse Softw are Reuse Practice Application system reuse widely practised as software systems are implemented as application families COTS reuse is becoming increasingly common Component reuse now seen as the key to effective and widespread reuse through Component Based Software Engineering CBSE However it is still relatively immature Function reuse libraries of reusable functions have been common for 40 years Benefits of Reuse Increased reliability when reused elements have been tried and tested in a variety of working systems Reduced process risk less uncertainty of cost compared to new development More effective use of specialists re use elements instead of experts Standards compliance when standards are embedded in reusable elements Accelerated development reduced development and validation time Requirements for Design with Reuse Must be possible to find appropriate reusable elements Must be confident that the elements will be reliable and will behave as specified Elements must be documented so that they can be understood and when necessary modified Reuse Problems e Increased maintenance costs especially if source code documentation absent e Lacks of tool support CASE toolsets do not support development with reuse e Not invented here syndrome Repositories of reusable elements techniques for classifying cataloguing
16. e An implementation has no legal standing as a contract Non functional requirements cannot be adequately represented in a system prototype Implementation Techniques Various techniques may be used for rapid development Dynamic high level language development Database programming 4G L s Component and application assembly e These are not mutually exclusive they are often used together e Visual programming is an inherent part of most prototype development systems Dynamic High level Languages Include powerful data management facilities often type less and interpretive Require large run time support system not normally used for large system development Some offer excellent G UI development facilities e Some have an integrated support environment whose facilities may be used in the prototype e Examples Lisp list structure based Prolog logic based and Smalltalk object oriented Choice of Prototyping Language e What is the application domain eg NLP matrix manipulation e What user interaction is required text based Web based e What support environment comes with the language e g tools components e What support environment comes with the language e g tools components e Different parts of the system may be programmed in different languages However there may be problems with language communications e A multi paradigm language e g LOOPS can reduce this
17. e Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project e A risk is a probability that some adverse circumstance will occur Project risks affect schedule or resources Product risks affect the quality or performance of the software being developed Business risks affect the organisation developing or procuring the software Taxonomy based on Effect Software Risks Risk Risk type Description Staff turnover Project Experienced staff will leave the project before it is finished Management change Project There will be achange of organisational management with ifferent priorities Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule Requirements change Project and There will be a larger number of product changes to the requirements than anticipate d Specification delays Project and Specifications of essential interfaces product are not available on schedule Size underestimate Project and The size of the system has been product underestimated CASE tool under Product CASE tools which support the performance project do not perform as anticipated Tec hnology change Business The underlying technology on which the system is built is superseded by new technology Product competition Business A competitive product is marketed before the system is completed The Risk Management
18. elicitation and analysis Requirements specification Requirements validation System models User and system requirements Requirements document Softw are Design and Implementation The process of producing an executable system based on the specification Software design design a software structure that realizes the specification Implementation translate this structure into an executable program The activities of specification design and implementation are closely related and may be inter leaved Design Process Activities High Level design activities e Architectural design subsystems and their relationships are identified e Abstract specification of each sub system s services e Interface design among sub systems Low Level design activities e Component design services allocated to different components and their interfaces are designed e Data structure design e Algorithm design The Software Design Process Requirements specification Architectural Interface design Abstract specification System architecture Interface specificaion TaI Data Component Ee structure specification ates specification Design activities Data structure design Component design f Algorithm design Algorithm specificaion Design products Software specification Design Methods Systematic canned approache
19. event scenarios to document system behaviour Data provided and delivered Control information Exception processing The next expected event e Multi threading supports description of exceptions Scenario fora Start Transaction Event UML Use cases and Sequence Diagrams Use cases are a graphical notation for representing abstract scenarios in the UML e They identify the actors in an interaction and describe the interaction itself e A set of use cases should describe all types of interactions with the system Sequence diagrams may be used to add detail to use cases by showing the sequence of event processing 30 Library Use cases aa Lending services ipF User administration na T Catalog services Library User Library Staff Supplier Catalogue Management Sequence Diagram Library Item Catalog Bookshop Cataloguer _ Supplier Library Staff 93 lt Acquire New lt Catalog Item zE Dispose Uncatalog Item Social and Organizational Factors e All software systems are used in a social and organizational context This can influence or even dominate the system requirements e Good analysts must be sensitive to these factors but there is currently no systematic way to tackle their analysis Example e Consider a system which allows senior management to access information without going through middle managers e Managerial status Senio
20. its require ments are frozen while requirements for later increments can continue to evolve Define outline requirements Develop system increment Design system architecture Integrate increment Assign requirements to increments Validate increment Final system System incomplete Incremental Development Advantages Useful functionality is delivered with each increment so customers derive value early Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure The highest priority system services tend to receive the most testing Potential Problem Requirements may NOT be partitionable into stand alone increments Extreme Programming Beck 99 Recent evolution of incremental approach based on e Development and delivery of very small increments of functionality e Significant customer involvement in process e Constant code improvement e Ego less pair wise programming NOT document oriented Gaining acceptance in some small organizations Representative of the agile development paradigm Boehm s Spiral Development Process is represented as a spiral rather than a sequence of activities Each loop in the spiral represents a phase in the process No fixed phases such as specification or design loops in the spiral are chosen depending on what is required Explicitly incorporates risk assessment and reso
21. lights on room siren on synthesizer on room break lights shutdown siren shutdown synthesizer shutdown windows shutdown doors shutdown movements shutdown run BuildingMonitor Control Systems A burglar alarm system is primarily a monitoring system It collects data from sensors but no real time actuator control Control systems are similar but in response to sensor values the system sends control signals to actuators e An example of a monitoring and control system is a system which monitors temperature and switches heaters on and off 77 A Temperature Control System 50Hz Thermostat plocess Switch command 500Ez Roomnumber Heater control process Data Acquisition Systems Collect data from sensors for subsequent processing and analysis e Datacollection processes and processing processes may have different periods and deadlines Thermosta process Furnace cantrol process Data collection may be faster than processing e g collecting information about an explosion e Circular or ring buffers are a mechanism for smoothing speed differences Reactor Data Collection e A system collects data from a set of sensors monitoring the neutron flux from a nuclear reactor e Flux data is placed in a ring buffer for later processing e The ring buffer is itself implemented as a concurrent process so that the collection and processing processe
22. problem Database Programming Languages Domain specific languages for business systems based around a database management system Normally include a database query language a screen generator a report generator and a spreadsheet e May be integrated with a CASE toolset e The language environment is some times known as a fourth generation language 4G L e Cost effective for small to medium sized business systems e Examples include Informix Appgen Sculptor and Power AGL DB programming Es Es erator Interface generator Spreadsheet language ee ee system Fourth generation language Component and Application Assembly Prototypes can be created quickly from a set of reusable components plus some mechanism to glue these components together The composition mechanism must include control facilities and a mechanism for component communication e Must take into account the availability and functionality of existing components Prototyping With Reuse e Application level development Entire application systems are integrated with the prototype so that their functionality can be shared For example if text preparation is required a standard word processor can be used e Component level development Individual components are integrated within a standard framework to implement the system Framework can be a scripting language or an integration framework such as CORBA DCOM o
23. successful Legacy System Change e Systems must change in order to remain useful e However changing legacy systems is often expensive e Different parts implemented by different teams so no consistent programming style e The system may use an obsolete programming language e The system documentation is often out of date e The system structure may be corrupted by many years of maintenance e Techniques to save space or increase speed at the expense of understandability may have been used e File structures used may be incompatible The Legacy Dilemma e Itis expensive and risky to replace the legacy system e It is expensive to maintain the legacy system Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re engineering Legacy System Structures e Legacy systems can be considered to be socio technical systems and not simply software systems e System hardware May be mainframe hardware Support software Operating systems and utilities e Application software Several different programs e Application data Data used by these programs that is often critical business information e Business processes The processes that support a business objective and which rely on the legacy software and hardware Business policies and rules Constraints on business operations Legacy System Components Embeds knowledge of Uses E Support Application software s
24. these allow objects to discover and refer to other objects on the network e Notification services these allow objects to notify other objects that an event has occurred Transaction services these support atomic transactions and rollback on failure Key Points e Almost all new large systems are distributed systems Distributed systems support resource sharing openness concurrency scalability fault tolerance and transparency Client server architectures involve services being delivered by servers to programs operating on clients e User interface software always runs on the client and data management on the server e Ina distributed object architecture there is no distinction between clients and servers 64 e Distributed object systems require middle ware to handle Activity object communications It is proposed to develop a system for stock information where e The CORBA standards are a set of middle ware standards dealers can access information about companies and can evaluate that support distributed object architectures various investment scenarios using a simulation system Activity Different dealers use this simulation in different ways according to their experience and the type of stocks that they are dealing with Suggest a client server architecture for this system that shows where functionality is located justify the client server Explain why distributed systems are inherently more scalable than c
25. which you know can only be met by asking your project team to work unpaid overtime All team members have young children Discuss whether you should accept this demand form your manager or whether you should persuade your team to give their time to the organization rather than their families What factors might be significant in your decision Activity As a programmer you are offered promotion to project management but you feel that you can make a more effective contribution in a technical rather than a managerial role D iscuss whether you should accept the promotion 19 ONIMAANIDON A AYVMLIOS LESSON 6 AND 7 SOFTWARE REQUIREMENTS Objectives e To introduce the concepts of abstract user and more detailed system requirements e To describe functional and non functional requirements e To explain two techniques for describing system requirements structured NL and PDLs e To suggest how software requirements may be organized in a requirements document Topics Covered e Functional and non functional requirements e User requirements e System requirements e The software requirements document Requirements Engineering e The process of eliciting analysing documenting and validating the services required of a system and the constraints under which it will operate and be developed e Descriptions of these services and constraints are the requirements for the system e Requirements may be high level and a
26. with standards Inspection Pre conditions Entry Criteria e A precise specification must be available Team members must be familiar with the organization standards e Syntactically correct code must be available for code inspections Inspection Pre conditions e An error checklist should be prepared e Management must accept the fact that inspection will increase costs early in the software process payoff comes later e Management must not use inspections results for staff appraisals D on t kill the goose that lays the golden eggs The Inspection Process Individual preparation Inspection Procedure e System overview presented to inspection team e Code and associated documents are distributed to inspection team in advance Inspection takes place and discovered errors are noted Modifications are made to repair discovered errors by owner e Re inspection may or may not be required Inspection Teams e Typically made up of 4 7 members e Author owner of the element being inspected Inspectors who find errors omissions and inconsistencies e Reader who steps through the element being reviewed with the team Moderator who chairs the meeting and notes discovered errors e Other roles are Scribe and Chief moderator Code Inspection Checklists Checklist of common errors should be used to drive individual preparation e Error checklist for is programming language de
27. 1 hardly matters to F extremely displeased 28 KARE Workbench Architecture Requirements Management Tool DOORS DOORS internal requirements database The system shall _ Interfaces AP233 Part 21 gt Requirements Formalisation Tool demanda l Somerville s VORD Method Viewpoint identification J VORD Standard Forms Viewpoint structuring J Viewpoint template Reference The viewpoint name Reference The service name Attributes Events Services Sub VPs Attributes providing viewpoint information A reference to a set of event scenarios describing how the system reacts to viewpoint events A reference to a set of service descriptions The names of sub viewpoints Knowledge Managem ent Tool Wisdom Viewpoint documentation f Service template Rationale Reason why the service provided Specification Reference toa list of service specifications These may be expressed in different notations List of viewpoint wr receiving the service Non functional Reference to a set of non requirements functional requirements which constrain the service Provider Reference toa list of system objects which provide the service Viewpoints Viewpoint system mapping ONIYSANIDNA AYVMLIOS Scenarios e Depict examples or scripts of possible system behaviour e People often relate to these more readily than to abstract statem
28. 1977 More recently use case descriptions Jacobsen Christerson et al 1993 have been used discuss these in the following chapter Mathematical These are notations based on mathematical concepts such as finite state machines or sets These unambiguous specifications reduce the arguments between customer and contractor about system functionality However most customers don t understand formal specifications and are reluctant to accept it as a system contract discuss formal specification in Chapter 9 specifications Program Description Languages PDLs e Requirements are specified operationally using pseudo code e Shows what is required by illustrating how the requirements could be satisfied e Especially useful when specifying a process that involves an ordered sequence of actions or when describing hardware and software interfaces Part of an ATM Specification class ATM declarations here public static void main String args throws InvalidCard try thisCard read may throw InvalidCard exception pin KeyPad readPin attempts 1 while thisCard pin equals pin amp attempts lt 4 pin KeyPad readPin attempts attempts 1 if thisCard pin equals pin throw new InvalidCard Bad PIN thisBalance thisCard getBalance do Screen prompt Please select a service service Screen touchKey switch service case Services withdrawalWithReceipt receip
29. Produce Check text final draft final draft Stage 2 Polishing Approved document Layout Review Produce Print text layout print masters copies Stage 3 Production Document Standards Document identification standards How documents are uniquely identified Document structure standards Standard structure for project documents e Document presentation standards Define fonts and styles use of logos etc e Document update standards Define how changes from previous versions are reflected in a document Document Interchange Standards Documents are produced using different systems and on different computers e Interchange standards allow electronic documents to be exchanged mailed etc Need for archiving The lifetime of word processing systems may be much less than the lifetime of the software being documented e XML is an emerging standard for document interchange which will be widely supported in future Process and Product Quality e The quality of a developed product is influenced by the quality of the production process e Particularly important in software development as some product quality attributes are hard to assess e However there is a very complex and poorly understood between software processes and product quality 121 Process based Quality Straightforward link between process and product in manufactured goods More complex for software because The application of individual skills and
30. Requirements change during the analysis process New stakeholders may emerge and the business environment may evolve e Organizational and political factors may influence the system requirements The Elicitation and Analysis Process Loquirement definition and View point oriented Elicitation e Stakeholders represent different ways of looking at a problem viewpoints e A multi perspective analysis is important as there is no single correct way to analyse system requirements e Provides a natural way to structure the elicitation process Types of Viewpoints e Data sources or sinks viewpoints are responsible for producing or consuming data Analysis involves checking that assumptions about sources and sinks are valid e Representation frameworks viewpoints represented by different system models i e dataflow ER finite state 27 machine etc Each model yields different insights into the system Receivers of services viewpoints are external to the system and receive services from it Natural to think of end users as external service receivers Method based RE e Structured methods to elicit analyse and document requirements Volere Requirements Process Fdajor Fisks 3 Initial Costs Reg vive nnen bs Reuse Formalized Fort srt ial Feqguirgn ate Guality Gateway Volere Requirement Shell Requirement Umiqueid Deserption A one sentence statement of the Rationale A justi
31. Textual Highlighting The filename you have chosen has been used Please choose an other name Ch 16 User interface design Data Visualisation e Concerned with techniques for displaying large amounts of information e Visualisation can reveal relationships between entities and trends in the data e Possible data visualisations are Weather information collected from a number of sources The state of a telephone network as a linked set of nodes Chemical plant visualised by showing pressures and tempera tures in a linked set of tanks and pipes A model of a molecule displayed in 3 dimensions Web pages displayed as a hyperbolic tree Colour Displays e Colour adds an extra dimension to an interface and can help the user understand complex information structures Can be used to highlight exceptional events e Common mistakes in the use of colour in interface design include The use of colour to communicate meaning Over use of colour in the display Colour Use Guidelines Don t use too many colours Use colour coding to support use tasks e Allow users to control colour coding Design for monochrome then add colour e Use colour coding consistently e Avoid colour pairings which clash Use colour change to show status change Be aware that colour displays are usually lower resolution User Support e User guidance covers all system facilities to support users including on line help error messages m
32. The SEI model classifies software processes as initial repeatable defined managed and optimising It identifies key processes which should be used at each of these levels The SEI model is appropriate for large systems developed by large teams of engineers It cannot be applied without modification in other situations e Processes can be classified as informal managed methodical and improving This classification can be used to identify process tool support Activity Under what circumstances is product quality likely to be determined by the quality of the development team Give examples of the types of software product that are particularly dependent on individual talent and ability 130 Activity Describe three types of software process metric that may be collected as par of a process improvement process Give one example of each type of metric Activity Consider the type of software process used in your organiza tion How many of the key process areas identified in the SEI model are used How would this model classify your level of process maturity Activity Give two advantages and two disadvantages of the approach to process assessment and improvement which is embodied in the SEI process maturity model Activity Suggest three specialized software tools which might be developed to support a process improvement programme in an organization Activity Suggest two application domains where the SEI capability mod
33. a class complexity of 1 and a large and complex method a much higher value The larger the value for this metric the more complex the object class Complex objects are more likely to be more difficult to understand They may not be logically cohesive so cannot be reused effectively as super classes in an inheritance tree Number of These are the number of operations in a super class which are over ridden overriding in a sub class A high value for this metric indicates that the super class operations used may not be an appropriate parent for the sub class Measurement Analysis e It is not always obvious what data means Analysing collected data is very difficult Professional statisticians should be consulted if available Data analysis must take local circumstances into account Measurement Surprises Reducing the number of faults in a program leads to an increased number of help desk calls The program is now thought of as more reliable and so has a wider more diverse market The percentage of users who call the help desk may have decreased but the total may increase A more reliable system is used in a different way from a system where users work around the faults This leads to more help desk calls 124 Key Points Software quality management is concerned with ensuring that software meets its required standards e Quality assurance procedures should be documented in an organisational quality manual e Software sta
34. a strategy for evolving these systems Scrap the system completely and modify business processes so that it is no longer required Continue maintaining the system Transform the system by re engineering to improve its maintainability Replace the system with a new system The strategy chosen should depend on the system quality and its business value System Quality and Business Value Business value High business value Low quality High business value High quality Low business value Low business value Low quality High quality System quality 134 Legacy System Categories Low quality low business value These systems should be scrapped Low quality high business value These make an important business contribution but are expensive to maintain Should be re engineered or replaced if a suitable system is available e High quality low business value Replace with COTS scrap completely or maintain e High quality high business value Continue in operation using normal system maintenance Business Value Assessment e Assessment should take different viewpoints into account System end users Business customers Line managers IT managers Senior managers e Interview different stakeholders and collate results System Quality Assessment e Business process assessment How well does the business process support the current goals of the business e Environment assessment How effective is the syste
35. a throw prototype system for a client who is very happy with it However she suggests that there is no need to develop another system but that you should deliver the prototype and offers an excellent price for the system You know that there may be future problems with maintaining the system Discuss how you might respond to this customer Notes 48 LECTURE 14 FORMAL SPECIFICATIONS Objectives To explain why formal specification helps discover problems in system requirements To describe the use of Algebraic specification techniques and Model based specification techniques including simple pre and post conditions Topics Covered Formal specification in the software process e Interface specification Behavioural specification Formal Methods Formal specification is part of a more general collection of techniques known as formal methods e All are based on the mathematical representations and analysis of requirements and software e Formal methods include Formal specification Specification analysis and property proofs Transformational development Program verification program correctness proofs e Specifications are expressed with precisely defined vocabulary syntax and semantics Acceptance and Use e Formal methods have not become mainstream as was once predicted especially in the US Other less costly software engineering techniques e g inspec tions reviews have be
36. algorithms Round robin Rate monotonic Shortest deadline first Monitoring and Control Systems e Important class of real time systems Continuously check sensors and take actions depending on sensor values Monitoring systems examine sensors and report their results Control systems take sensor values and control hardware actuators Burglar Alarm System e A system is required to monitor sensors on doors and windows to detect the presence of intruders in a building e When a sensor indicates a break in the system switches on lights around the area and calls police automatically e Sensors Movement detectors window sensors door sensors 50 window sensors 30 door sensors and 200 movement detectors Voltage drop sensor 76 e Actions When an intruder is detected police are called automatically Lights are switched on in rooms with active sensors An audible alarm is switched on The system switches automatically to backup power when a voltage drop is detected The R T System Design Process e Identify stimuli and associated responses Define the timing constraints associated with each stimulus and response e Allocate system functions to concurrent processes Design algorithms for stimulus processing and response generation Design a scheduling system which ensures that processes will always be scheduled to meet their deadlines Stimuli to be Processed e Power failure Generated aperiodicall
37. an open ended budget and you may choose a project team of yup to five people form any other projects going on in the company However a rival company working in the same area is actively recruiting staff and several staff working for your company has left to join them Describe tow models of programming team organization that might be used in this situation and make a choice of one of these models Give reasons for your choice and explain why you have rejected the alternative model Activity Why are open plan and communal offices sometimes less suitable for software development than individual officers Under what circumstances do you think that open plan environments might be better Activity Why is the P CMM an effective framework for improving the management of people in an organization Suggest how it may have to be modified if it is to be used in small companies 110 Activity Should managers become friendly and mix socially with more junior members of their group Activity Is it ethical to provide the answers which you think the tester wants rather than saying what you really feel when taking psychological tests Notes 111 ONIMAANIDN A AYVMLIOS LESSON 31 AND 32 SOFTWARE COST ESTIMATION Predicting the resources required for a software development process Objectives To introduce the fundamentals of software costing and pricing e To describe three metrics for software productivity assessment
38. and retrieving elements are immature e Finding understanding and adapting reusable elements takes time Component based Development e Component Based Software Engineering CBSE is a development approach based on systematic reuse e CBSE emerged in the late 1990 s due to failure of OO development to lead to extensive reuse e Components are designed to be general service providers Critical Characteristics of a Reusable Component e An independent executable entity source code is typically not available so the component is not compiled with other system elements e All interactions are through a published 2 part interface internal state is never exposed Component Interface e Provides interface defines the services that are provided by the component to other system elements e Requires interface defines the services that must be made available to the component by other system elements in order to operate Component Interfaces Requires interface Provides interface Printing Services Component Requires interface Provides interface Printer description e nregister Control interface 81 Component Abstraction Levels e Functional abstraction implements a single function e g square root Casual groupings loosely related entities such as data declarations and functions Data abstractions a data abstraction or object class Cluster abstractions related ob
39. and that it should be replaced by a new system This will mean that a number of system maintainers are made redundant Y our assessment actually shoes that the system is well maintained and is of high quality and high business value How would you report these results to the management of the organization Notes 138 LESSON 37 SOFTWARE CHANGE Managing the Processes of Softw are System Change Objectives To explain different strategies for changing software systems Software maintenance Architectural evolution Software re engineering To explain the principles of software maintenance e To describe the transformation of legacy systems from centralised to distributed architectures Topics Covered e Program evolution dynamics Software maintenance e Architectural evolution Softw are Change Software change is inevitable New requirements emerge when the software is used The business environment changes Errors must be repaired New equipment must be accommodated The performance or reliability may have to be improved e A key problem for organisations is implementing and managing change to their legacy systems Softw are Change Strategies Software maintenance Changes are made in response to changed requirements but the fundamental software structure is stable e Architectural transformation The architecture of the system is modified generally from a centralised architecture to a distributed architect
40. based on the system specification e Structural testing identifies test cases which cause all paths through the program to be executed Test coverage measures ensure that all statements have been executed at least once e Interface defects arise because of specification misreading misunderstanding errors or invalid timing assumptions e To test object classes test all operations attributes and states e Integrate object oriented systems around clusters of objects Activity Discuss the differences between black box and structural testing and suggest how they can be used together in the defect testing process Activity What testing problems might arise in numerical routines designed to handle very large and very small numbers 102 Activity Derive a set of test for the following components e A sort routine which sorts arrays of integers e A routine which takes a line of text as input and counts the number of non blank characters in that line Activity Show using a small example why it is practically impossible to exhaustively test a program Activity Explain why interface testing is necessary given that individual units have been extensively validated through unit testing and program inspections Activity Explain why bottom up and top down testing may be inappropriate testing strategies for object oriented systems 103 ONIMSANIDN A AYVMLIOS LESSON 29 AND 30 MANAGING PEOPLE Managing People Workin
41. between client and developer e Software design specification implementation oriented abstract description of software design which may utilize formal mathematical notations Written for developers User and System Requirements 1 The software must provice a means of representing and accessing external files created by other tools 1 The user should be provided with facilities to define the type of external files 2 Each external file type may have an associated tool which may be applied to the file 3 Each external file type may be represented as a specific icon on the user s display 4 Facilities should be provided for the icon representing an external file type to be defined by the user 5 When a user selects an icon representing an external file the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon Requirements Readers Client managers System end users Client engineers Contractor managers System architects User requirements System end users Client engineers System architects Software developers System requirements 20 Functional and Non functional Requirements e Functional requirements services the system should provide how it should react to particular inputs or how it should behave in particular situations e Non functional requirements constraints on services or functions e g response tim
42. code and the file structure implied in these names differs form that of the target machine Write a set of programmer s guidelines which help avoid this and other system building problems which you can think of Activity Describe five factors which must be taken into account by engineers during the process of building a release of a large software system Activity Describe two ways in which system building tools can optimize the process of building a version of a system form its compo nents 155 ONIMSANIDN A AYVMLIOS The lesson content has been compiled from various sources in public domain including but not limited to the internet for the convenience of the users The university has no proprietary right on the same fe Pal DER P W Rai Technology University ENGINEERING MINDS Rai Technology University Campus Dhodballapur Nelmangala Road SH 74 Off Highway 207 Dhodballapur Taluk Bangalore 561204 E mail info raitechuniversity in Web www raitechuniversity in
43. component to fail e Use stress testing in message passing systems e In shared memory systems vary the order in which components are activated Stress Testing e Exercises the system beyond its maximum design load Stressing the system often causes defects to come to light e Stressing the system test failure behaviour Systems should not fail catastrophically Stress testing checks for unacceptable loss of service or data e Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded Object oriented Testing The components to be tested are object classes that are instantiated as objects e Larger grain than individual functions so approaches to white box testing have to be extended e No obvious top to the system for top down integration and testing Testing Levels e Testing operations associated with objects Testing object classes Testing clusters of cooperating objects Testing the complete OO system Object Class Testing e Complete test coverage of a class involves Testing all operations associated with an object Setting and interrogating all object attributes Exercising the object in all possible states e Inheritance makes it more difficult to design object class tests as the information to be tested is not localised Weather Station Object Interface Weather Station identifier reportWeather calibrate instruments test startup inst
44. de2 seconds e Attributes are often emergent system properties i e only observable when the entire system is operational e Process constraints may mandate a particular CASE system programming language or development method e Non functional requirements may be more critical than functional requirements If not met the system may be useless Non functional Classifications e Product requirements specify product behaviour e Organizational requirements derived from policies procedures in customer s or developer s organization e g process constraints e External requirements derived from factors external to the product and its development process e g interoperability requirements legislative requirements Non functional Classifications Non functional requirements Or ganizatio nal External requirements requirements Ef ficiency Reliability Portability Interoperability Ethical requirements requirements requirements requirements requirements Usability requirements Performance Space requirements requirements Delivery Implementation Standards Legislative requirements requirements requirements requirements Privacy Safety requirements requirements 21 Examples e Product requirement 4 C 8 it shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set e Organisational requirement 9 3 2 the system development process and
45. df the versions of component that are used in thecurrentsystem Test data Does test data for the system exist Is there a record of regression tsts carried out when newfeatures have ben addedto thesystem Personnelskills Are there people avalable who havethe skills to mantain the applicatior Are there only a imited numler of peop who un rstand the system System Measurement e You may collect quantitative data to make an assessment of the quality of the application system The number of system change requests The number of different user interfaces used by the system The volume of data used by the system Key Points e A legacy system is an old system that still provides essential business services e Legacy systems are not just application software but also include business processes support software and hardware e Most legacy systems are made up of several different programs and shared data e A function oriented approach has been used in the design of most legacy systems e The structure of legacy business systems normally follows an input process output model e The business value of a system and its quality should be used to choose an evolution strategy The business value reflects the system s effectiveness in supporting business goals e System quality depends on business processes the system s environment and the application software 135 ONIMAANIDN A JAVMI OS Activity Explain why legacy systems m
46. during analysis Inheritance graphs of analysis design and implementation have different functions Inheritance and OOD e Inheritance is a useful implementation concept which allows reuse of attribute and operation definitions Some feel that identifying an inheritance hierarchy or network is also a fundamental part of object oriented design Obviously this can only be implemented using an OO PL e Others feel this places unnecessary restrictions on the implementation e Inheritance introduces complexity and this is undesirable especially in critical systems UML Associations e Objects and object classes participate in various types of relationships with other objects and object classes e Inthe UML a generalized relationship is indicated by an association e Associations may be annotated with information that describes their nature e Associations can be used to indicate that an attribute of an object is an associated object or that a method relies on an associated object Concurrent Objects The nature of objects as self contained entities make them well suited for con current implementation An Association Model Employee is managed by is member of manages e The message passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system Concurrent object implementation servers and active objects e Server
47. eather station Use case Report Actors W eather data collection system W eather station Data The weather station sends a summary of the weather data that has been collected from the instruments in the collection period to the weather data collection system The data sent are the maximum minimum and average ground and air temperatures the maximum minimum and average air pressures the maximum minimum and average wind speeds the total rainfall and the wind direction as sampled at 5 minute intervals Stimulus The weather data collection system establishes a modem link with the weather station and requests transmission of the data Response The summarised data is sent to the weather data collection system Comments Weather stations are usually asked to report once per hour but this frequency may differ from one station to the other and may be modified in future 2 Design System Architecture e A layered architecture is appropriate for the weather station Interface layer for handling communications Data collection layer for managing instruments Instruments layer for collecting data e Rule of Thumb There should be no more than 7 entities in an architectural model 69 Weather Station Architecture Weather station subsystem Interface subsystem Data collection a Package of IN Subsystem instruments for raw nstruments data collections UML nested pack ages UML annotations 3 Id
48. highlighting e The basic building blocks of Z based specifications are schemas Schemas identify state variables and define constraints and operations in terms of those variables The Structure of A Z Schema Schema name Schema signature Schema predicate Container contents M capacity M contents lt capacity invariants pre amp post conditions An Insulin Pump Insulin reservoir insulin Needle assembly delivery Sensor glucose level Display text messages Power supply Modelling The Insulin Pump e The schema models the insulin pump as a number of state variables reading from sensor dose cumulative dose T0 r1 r2 last 3 readings capacity pump reservoir alarm signals exceptional conditions pump output for pump device display1 display2 text messages amp dose e Names followed by a are inputs names followed by a are outputs Schema Invariant e Each Z schema has an invariant part which defines conditions that are always true schema predicates For the insulin pump schema it is always true that The dose must be less than or equal to the capacity of the insulin reservoir 50 No single dose may be more than 5 units of insulin and the total dose delivered in a time period must not exceed 50 units of insulin This is a safety constraint display1 shows the status of the insulin reservoir Insulin Pump Schema Ins ukin_ pump AAA readin
49. holder for the result of the service e In practice messages are often implemented by procedure calls Message Examples Call amethod associated with a buffer object that returns the next value in the buffer v circularBuffer G et Call the method associated with a thermostat object that sets the temperature to be maintained thermostat setT emp 20 Generalization and Inheritance Objects are members of classes which define attribute types and operations e Classes may be arranged in a hierarchy where one class a super class is a generalization of one or more other classes sub classes e A sub class inherits the attributes and operations from its super class and may add new methods or attributes of its own A UML Generalisation Hierarchy Employee i Programmer project progLanguage budgetsControlled dateAppointed Project Strategic Manager I Manager Dept Manager projects responsibilities Advantages of Inheritance e Itis an abstraction mechanism which may be used to classify entities Itis a reuse mechanism at both the design and the programming level The inheritance graph is a source of organisational knowledge about domains and systems Problems With Inheritance e Object classes are not self contained i e they cannot be understood without reference to their super classes e Designers have a tendency to reuse the inheritance graph created
50. in the object oriented design process To introduce various models used to describe an object oriented design To show how the UML may be used to represent these models Topics Covered Objects and object classes e An object oriented design process e Design evolution Characteristics of OOD e Allows designers to think in terms of interacting objects that maintain their own state and provide operations on that state instead of a set of functions operating on shared data e Objects hide information about the representation of state and hence limit access to it e Objects may be distributed and may work sequentially or in parallel A design strategy based on information hiding e A useful definition of information hiding Potentially changeable design decisions are isolated ie hidden to minimize the impact of change David Parnas Interacting Objects ops1 03 C3 state 03 opss ops 4 ops5 opss opsi Advantages of OOD e Easier maintenance Objects may be understood as stand alone entities e Objects are appropriate reusable components For some systems there is an obvious mapping from real world entities to system objects Object oriented Development e OO Analysis concemed with developing an object model of the application domain e OO Design concerned with developing an object oriented system model to implement requirements e OO Programming
51. inherently flexible and subject to change As requirements change through changing business circum stances the software that supports the business must also evolve and change The distinction between development and evolution is increasingly irrelevant as fewer and fewer systems are completely new Define system requirements Assess existing systems Existing New Automated Process Support Case Computer aided software engineering CASE is software to support software development and evolution processes Activity automation e Graphical editors for system model development e Data dictionaries for name management e GUI builders for user interface construction e Debuggers to support program faultfinding e Automated translators to generate new versions of a program e g restructuring tools CASE Technology CASE technology has led to significant improvements in the software process but not the order of magnitude improve ments that were once predicted e Software engineering involves design activity requiring creative thought this is not readily automatable e Software engineering is a team activity and for large projects much time is spent in team interactions CASE technology does not support this well CASE Classification Classification helps us understand the different types of CASE tools systems and their support for process activities Functional perspective tools are classified acco
52. is a close relationship between the CASE tools and the CM tools e More commonly the CM database is maintained separately as this is cheaper and more flexible Change Management e Software systems are subject to continual change requests From users From developers From market forces e Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost effective way The Change Management Process Request change by completing a change request form Analyze change request if change is valid then Assess how change might be implemented Assess change cost Submit request to change control board if change is accepted then repeat make changes to software submit changed software for quality approval until software quality is adequate create new system version else reject change request else reject change request Change Request Form Definition of change request form is part of the CM planning process e Records change required suggestor of change reason why change was suggested and urgency of change from requestor of the change Records change evaluation impact analysis change cost and recommendations System maintenance staff Change Request Form Project Proteus PCL Tools Number 23 94 Change requester I Sommerville Date 1 12 98 Requested change When a component is selected from the structure display the name of the file where it is stored Chan
53. make them more responsive and more efficient Often reliant on the introduction of new computer systems to support the revised processes e May force software re engineering as the legacy systems are designed to support existing processes Forward Engineering And Re engineering System Design and specification implementation Forward engineering Existing Understanding and software system transformation Software re engineering The Re engineering Process ere Program program Program modularis ation Structured program Re engineering Cost Factors The quality of the software to be re engineered The tool support available for re engineering Re engineered system Modularised Original data program Data reengineering Reengineered daa Reverse engineering Program structure improvement Source code translation The extent of the data conversion which is required e The availability of expert staff for re engineering Re engineering Approaches Automated program restructuring Automated source code conversion Program and data restructuring Automated restructuring with manual changes Restructuring plus architectural changes oA Increased cost Source Code Translation Involves converting the code from one language or language version to another e g FORTRAN to C e May be necessary because of Hardware platform update Staff skill shortage
54. models and rules and guidelines that should apply to the models e CASE tools support system modelling as part of a structured method Method Weaknesses e They do not model non functional system requirements e They do not usually include information about whether a method is appropriate for a given problem e The may produce too much documentation e The system models are sometimes too detailed and difficult for users to understand Model Types Data processing model showing how the data is processed at different stages Composition model showing how entities are composed of other entities e Architectural model showing principal sub systems Classification model showing how entities have common characteristics e Stimulus response model showing the system s reaction to events Context Models e Context models are used to illustrate the boundaries of a system Social and organisational concerns may affect the decision on where to position system boundaries e Architectural models show the a system and its relationship with other systems The Context of An ATM System Security system Branch Account system Auto teller system Main tenance system Branch counter system Process Models e Process models show the overall process and the processes that are supported by the system Data flow models may be used to show the processes and the flow of information from on
55. new logic must be installed on each client A Client server ATM System Account server Tele processing monitor Customer account database 62 Three tier Architectures Each application architecture layer may execute on a separate processor Allows for better performance and scalability than a thin client approach and is simpler to manage than a fat client approach A 3 tier C S Architecture Presentation Server Server Data management Application processing An Internet Banking System HTTP interaction Web server Account service provision Customer account database SQL query SQL Use of C S Architectures Architecture Two tier C S architecture with thin clients Applications Legacy system applications where separating application processing and data management is impractical Computationally intensive applications such as compilers with little or no data management Data intensive applications browsing and querying with little or no application processing Applications where application processing is provided by COTS e g Microsoft Excel on the client Applications where computationally intensive processing of data e g data visualisation is required Applications with relatively stable end user functionality used in an environment with well established system management Two tier C S architecture with fat clients Three tier or Lar
56. produce an executable system based on the specification V amp V involves checking that the system meets its specification and satisfies user needs Evolution is concerned with modifying the system after it is placed in use CASE technology supports software process activities Activity Giving reasons for your answer based on the type of system being developed suggest the most appropriate generic software process model which might be used as a basis for managing the development of the following systems e A system to control anti lock braking in a car e A virtual reality system to support software maintenance e A university accounting system that replaces an existing system e An interactive system for railway passengers that finds train times from terminals installed in stations 10 Activity Explain why programs which are developed using evolutionary development are likely to be difficult to maintain Activity Explain how both the waterfall model of the software process and the prototyping model can be accommodated in the spiral process model Activity Suggest why it is important to make a distinction between developing the user requirements and developing the system requirements in the requirements engineering process Activity Describe the main activities in the software design process and the outputs of these activities Using an entity relation diagram show possible relationships between the outputs of
57. program evolution Organisational stability Applicability of Lehman s Laws e This has not yet been established e They are generally applicable to large tailored systems developed by large organisations e It is not clear how they should be modified for Shrink wrapped software products Systems that incorporate a significant number of COTS components Small organisations Medium sized systems Software Maintenance Modifying a program after it has been put into use e Maintenance does not normally involve major changes to the system s architecture e Changes are implemented by modifying existing components and adding new components to the system Maintenance is Inevitable e The system requirements are likely to change while the system is being developed because the environment is changing Therefore a delivered system won t meet its requirements e Systems are tightly coupled with their environment When a system is installed in an environment it changes that environment and therefore changes the system requirements e Systems MUST be maintained therefore if they are to remain useful in an environment Types of Maintenance e Maintenance to repair software faults Changing a system to correct deficiencies in the way meets its requirements e Maintenance to adapt software to a different operating environment 139 Changing a system so that it operates in a different environ ment computer OS etc from its
58. programming or evolutionary prototyping Evolutionary development Concurr ert activities Outline description Potential Problems e Lack of process visibility e Final version prototype is often poorly structured e Special skills e g in languages for rapid prototyping may be required Applicability e For small or medium size interactive systems e For parts of large systems e g the user interface e For short lifetime systems in case of exploratory development Formal Systems Development Based on the transformation of a mathematical specification through different representations to an executable program Transformations are correctness preserving so it is possible to show that the program conforms to its specification Embodied in Mills Clean room approach to software development Requirements Formal Formal Integration and definition specification transformation system testing Formal Transformations Formal transformations Ti T2 T3 T4 Formal specification Proofs of transformation correctness Problems e Need for specialized skills and training to apply the technique e Difficult to formally specify some aspects of the system such as the user interface thus focus is usually limited to functional requirements Applicability e Critical systems especially those where a safety or security case must be made before the system is put into operation e Critical parts of larg
59. repairing these defects Defect locating is analogous to detective work or medical diagnosis Software Inspections Reviews e Involve people examining a system representation requirements design source code etc with the aim of discovering anomalies and defects They do not require execution so may be used before system implementation e Can be more effective than testing after system implementation As demonstrated in many studies Why Code Inspections can be so Effective e Many different defects may be discovered in a single inspection In testing one defect may mask others so several executions may be required They reuse domain and programming language knowledge Reviewers are likely to have seen the types of error that commonly occur Inspections and Testing are Complementary Inspections can be used early with non executable entities and with source code at the module and component levels Testing can validate dynamic behaviour and is the only effective technique at the sub system and system code levels e Inspections cannot directly check non functional requirements such as performance usability etc Program Inspections Reviews Formalised approaches to document walk throughs or desk checking e Intended exclusively for defect DETECTION not correction 93 Defects may be logical errors anomalies in the code that might indicate an erroneous condition or non compliance
60. same application domain e Advantages Accurate if project data available e Disadvantages Impossible if no comparable project has been tackled Needs systematically maintained cost database Parkinson s Law The project costs whatever resources are available e Advantages No overspend e Disadvantages System is usually unfinished Pricing to Win The project costs whatever the customer has to spend on it e Advantages You get the contract Disadvantages The probability that the customer gets the system he or she wants is small Costs do not accurately reflect the work required Top down and Bottom up Estimation e Any of these approaches may be used top down or bottom up e Top down Start at the system level and assess the overall system functionali ty and how this is delivered through sub systems Bottom up Start at the component level and estimate the effort required for each component Add these efforts to reach a final estimate Top down Estimation Usable without knowledge of the system architecture and the components that might be part of the system Takes into account costs such as integration configuration management and documentation e Can underestimate the cost of solving difficult low level technical problems Bottom up Estimation e Usable when the architecture of the system is known and components identified e Accurate method if the system has been designed in detail e May underestimate costs of sys
61. skilled IT staff Project Planning e Probably the most time consuming project management activity or at least it should be e Continuous activity from initial concept to system delivery Plans must be regularly revised as new information becomes available e Different types of sub plans may be developed to support a main software project plan concerned with overall schedule and budget Types of Project Sub plans Plan l Description Quality plan Describes the quality procedures and _standards that will be used in a project Validation plan Describes the approach resources and schedule used for system validation Configuration Describes the configuration management management plan procedures and structures to be used Maintenance plan Predicts the maintenance requirements of the system maintenance costs and effort required Staff development plan Describes how the skills and experience of the project team members will be developed Project Planning e The plan is nothing the planning is everything Dwight Eisenhower on the D Day invasion plan 13 Project Planning Process Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverables while project has not been completed or canceled loop Draw up project schedule Initiate activities according to schedule Wait for a while Revise estimates of project sched
62. software meets the real needs of its users without causing damage to them or to the environment The approach that I take in this book is to present a broad perspective on software engineering and I don t concentrate on any specific methods or tools There are no simple solutions to the problems of software engineering and we need a wide spectrum of tools and techniques to solve software engineer ing problems Software Engineering Lesson No Topic Page No Lesson 1 Introduction 1 Lesson 2 Software Processes 6 Lesson 3 Software Processes 9 Lesson 4 Project Management Lesson 5 Project Management Lesson 6 Software Requirements 2 2 Lesson 7 Lesson 8 Lesson 9 Software Requirements Requirements Engineering Process Requirements Engineering Process 2 3 Lesson 11 System Models Lesson 12 Lesson 13 Lesson 14 3 Lesson 15 Architectural D esign 4 Software Prototyping Software Prototyping Formal Specifications 4 4 Lesson 16 Architectural D esign Lesspn 17 Lesson 18 Lesson 19 13 16 0 3 7 1 39 5 9 7 1 Distributed Systems Architectures Distributed Systems Architectures Object Oriented D esign 5 5 6 6 4 Lesson 20 Object Oriented D esign Lesson 21 Real time Software D esign Lesson 22 Real time Software D esign Lesson 26 Verification and Validation Lesson 24 User Interface D esign Lesson 27 Software Testing 9 Lesson 28 Lesson 29 i 7 7 7
63. structure Knowledge of the program is used to identify additional test cases e Objective is to exercise all program statements not all path combinations Tests Derives 98 Binary Search Java class BinSearch This is an encapsulation of a binary search function that takes an array of ordered objects and a key and returns an cbject with 2 attributes namely index the value of the array index found a boolean indicating whether or not the key is in the array An object is retumed because it is not possible in Java to pass basic types by reference to afunction and so return two values the key is 1 if the dement is not found public static void search int key int elemArray Result r int bottom 0 int top demArray length 1 int mid r found false r index 1 while bottom lt top mid top bottom 2 if elemArray mid key index mid r found true return if part else if elemArray mid lt key bottom nd 1 else top mid 1 Avhile loop search BinSearch Binary Search Equiv Partitions e Pre conditions satisfied key element in array e Pre conditions satisfied key element not in array e Pre conditions unsatisfied key element in array e Pre conditions unsatisfied key element not in array e Input array has a single value Input array has an even number of values Input array has an odd num
64. system e System administrator s manual Describes how to manage the system when it is in use User Interface Evaluation Some evaluation of a user interface design should be carried out to assess its suitability 89 e Full scale evaluation is very expensive and impractical for most systems e Ideally an interface should be evaluated against a usability specification However it is rare for such specifications to be produced Usability Attributes Attribute Description Learnability How long does it take a new user to become productive with the system Speed of operation How well does the system response match the user s work practice Robustness How tolerant is the system of user error Recoverability How good is the system at recovering from user errors Adaptability How closely is the system tied to a single model of work Simple Evaluation Techniques e Questionnaires for user feedback Video recording of system use and subsequent tape evaluation e Instrumentation of code to collect information about facility use and user errors The provision of a grip button for on line user feedback Key Points e Interface design should be user centred An interface should be logical and consistent and help users recover from errors e Interaction styles include direct manipulation menu systems form fill in command languages and natural language Graphical displays should be used
65. the bank identifier the account number and the user s personal identifier They also derive account information from a central database and update that database on completion of a transaction Using your knowledge of ATM operation write Z schemas defining the state of the system card valida tion where the user s identifier is checked and cash withdrawal Activity You are a systems engineer and you are asked to suggest the best way to develop the safety software for a heart pacemaker You suggest formally specifying the system but your sugges tion is rejected by your manager You think his reasons are weak and based on prejudice Is it ethical to develop the system using methods that you think are inadequate 53 ONIMSANIDNA AYVMLIOS LESSON15 AND 16 ARCHITECTURAL DESIGN Establishing The Overall Structure of a Software System Objectives e To introduce architectural design and to discuss its importance e To explain why multiple models are required to document in architecture e To describe types of architectural models that may be used e To discuss use of domain specific architectural reference models Topics Covered e Architectural design e System structuring Control models Modular decomposition Domain specific architectures What is Architectural Design The process of identifying the sub systems making up a system and a framework for sub system control and communication e A boot strapping
66. the nominal schedule for the project e The time required is independent of the number of people working on the project Staffing Requirements e Staff required can t be computed by diving the development time by the required schedule The number of people working on a project varies depending on the phase of the project The more people who work on the project the more total effort is usually required e A very rapid build up of people often correlates with schedule slippage Key Points Factors affecting productivity include individual aptitude domain experience the development project the project size tool support and the working environment e Different techniques of cost estimation should be used when estimating costs Software may be priced to gain a contract and the functionality adjusted to the price Algorithmic cost estimation is difficult because of the need to estimate attributes of the finished product The COCOMO model takes project product personnel and hardware attributes into account when predicting effort required e Algorithmic cost models support quantitative option analysis The time to complete a project is not proportional to the number of people working on the project Activity Describe two metrics that have been used to measure program mer productivity Comment briefly on the advantages and disadvantages of these metrics Activity Cost estimates are inherently risky irrespecti
67. the people that they work with Group Working Most software engineering is a group activity The development schedule for most non trivial software projects is such that they cannot be completed by one person working alone Group interaction is a key determinant of group performance e Flexibility in group composition is limited Managers must do the best they can with available people Time Distribution 20 Non productive activ ities 50 Interaction with other people 30 Working alone Group Composition e Group composed of members who share the same motivation can be problematic Task oriented everyone wants to do their own thing Self oriented everyone wants to be the boss Interaction oriented too much chatting not enough work e An effective group has a balance of all types e Can be difficult to achieve because most engineers are task oriented e Need for all members to be involved in decisions which affect the group Group Leadership Leadership depends on respect not titular status There may be both a technical and an administrative leader e Democratic leadership is more effective that autocratic leadership e A career path based on technical competence should be supported Group Cohesiveness e Ina cohesive group members consider the group to be more important than any individual in it e Advantages of a cohesive group are Group quality standards can be developed G
68. these activities 11 ONIMSANIDN A AYVMLIOS ONIMAANIDN A AYVMLIOS Activity What are the five components of a design method Take any method which you know and describe its components Assess the completeness of the method which you have chosen Activity Design a process model for running system tests and recording their results Activity Explain why a software system that is used in a real world environment must change or become progressively less useful Activity Suggest how a CASE technology classification scheme may be helpful to managers responsible for CASE system procure ment 12 LESSON 4 AND 5 PROJECT MANAGEMENT Organizing Planning and Scheduling Software Projects Objectives e To introduce software project management and to describe its distinctive characteristics e To discuss project planning and the planning process e To show how graphical schedule representations are used by project management e To discuss the notion of risks and the risk management process Topics Covered e Management activities e Project planning e Project scheduling e Risk management Softw are Project Management e Concerned with activities involved in ensuring that software is delivered on time within budget and in accordance with the requirements of the organizations developing and procuring the software e Project management is needed because software development is always subject to budget and schedul
69. to be referred to the client Software Measurement and Metrics Software measurement is concerned with deriving a numeric value for an attribute of a software product or process This allows for objective comparisons between techniques and processes e Although some companies have introduced measurement programmes the systematic use of measurement is still uncommon e There are few standards in this area Software M etric e Any type of measurement which relates to a software system process or related documentation Lines of code in a program the Fog index and number of person days required to develop a component e Allow the software and the software process to be quantified e Measures of the software process or product e May be used to predict product attributes or to control the software process Predictor and Control Metrics Software Software process product Predictor measurements Control measurements Management decisions Metrics Assumptions e A software property can be measured e The relationship exists between what we can measure and what we want to know e This relationship has been formalized and validated e It may be difficult to relate what can be measured to desirable quality attributes Internal and External Attributes The Measurement Process e A software measurement process may be part of a quality control process Data collected during this process sh
70. to present trends and approximate values Digital displays when precision is required Colour should be used sparingly and consistently e Systems should provide on line help This should include help I m in trouble and help I want information e Error messages should be positive rather than negative e A range of different types of user documents should be provided e Ideally a user interface should be evaluated against a usability specification Activity Suggest situations where it is unwise or impossible to provide a consistent user interface Activity What factors have to be taken into account when designing menu based interface for walkup systems such as bank ATM machines Write a critical commentary on the interface of an ATM that you use 90 Activity Suggest ways in which the user interface to an e commerce system such as an online bookstore or music retailer might be adapted for users who are physically challenged with some form of casual impairment or problems with muscular control Activity Discuss the advantages of graphical information display and suggest four applications where it would be more appropriate to use graphical rather than digital displays of numeric informa tion Activity What are the guidelines which should be followed when using color in a user interface Suggest how color might be used more effectively in the interface of an application system that you use Acti
71. Architectures Distributed Systems Architectures Multiprocessor Architectures Client Server Architectures Distributed Object Architectures CORBA Common Object Request Broker Architecture Software Design Object Oriented Design Objects and Object Classes Object Oriented Design Process Design Evolution Real Time Software Design Systems Design Real Time Executives Monitoring and Control Systems Data Acquisition Systems Design with Reuse Component Based Development Application Families Design Patterns User Interface Design Principles User Interaction Information Presentation User Support Interface Evaluation Verification Validation and Testing Verification and Validation V amp V Static and Dynamic V amp V V amp V Goals V amp V vs Debugging Software Inspections Reviews Clean Room Software Development Software Testing Defect Testing Integration Testing Interface Testing Object Oriented Testing Testing Workbenches Managing People Introduction Limits to Thinking Memory Organization Knowledge Modeling Motivation Group Working Choosing and Keeping People the People Capability Maturity Model Software Cost Estimation and Quality Management Software Cost Estimation Productivity Estimation Techniques Algorithmic Cost Modelling Project Duration and Staffing Quality Management Quality Assurance and Standards Quality Planning Quality Control Software Measurement and Metrics Process Improvement Pr
72. ENGINEERING MINDS Software Engineering Pye rq i tN ots east Vog Ai Wl ss Subject SOFTWARE ENGINEERING Credit 4 SYLLABUS Overview Introduction FAQs about Software Engineering Professional and Ethical Responsibility Software Process Models Process Iteration Specification Software Design and Implementation Verification amp Validation Software Evolution Automated Process Support Software Project Management and Requirements Project Management Management Activities Project Pl Software Project Management and Requirements Project Management Management Activities Project Planning Project Scheduling Risk Management Software Requirements Functional and Non Functional Requirements User Requirements System Requirements Requirements Document Requirements Engineering Process Feasibility Studies Requirements Elicitation and Analysis Requirements Validation Requirements Management System Models Software Prototyping and Specifications System Models Software Prototyping and Specifications System models Context Behavioural Data and Object models CASE Workbenches Software Prototyping Prototyping in the Software Process Rapid Prototyping Techniques User Interface Prototyping Specifications Formal Specification in the Software Process Interface Specification Behavioural Specification Architectural Design Introduction System Structuring Control Models Modular Decomposition Domain Specific
73. EX Pre condition the array has at least one element T FIRST lt T LAST Post condition the element is found and is referenced by L Found and T L Key or the element is not in the array Not Found and not exists i T FIRST gt i lt T LAST T i Key Search Routine Input Partitions Inputs which conform to the pre conditions e Inputs where a pre condition does not hold e Inputs where the key element is a member of the array e Inputs where the key element is not a member of the array Testing Guidelines Sequences e Test software with sequences which have only a single value e Use sequences of different sizes in different tests e Derive tests so that the first middle and last elements of the sequence are accessed e Test with sequences of zero length Search Routine Input Partitions Array Element Single value In sequence Single value Not in sequence More than 1 value More than 1 value More than 1 value More than 1 value First element in sequence Last element in sequence Middle element in sequence Not in sequence Input sequence T Key Key Output Found L 17 17 true 1 17 0 false 17 29 21 23 17 true 1 41 18 9 31 30 16 45 45 true 7 17 18 21 23 29 41 38 23 true 4 21 23 29 33 38 25 false White box Testing Sometimes called Structural testing Derivation of test cases according to program
74. Management e Requirements management is the process of managing changing requirements during the requirements engineering process and system development New requirements emerge during the process as business needs change and a better understanding of the system is developed The priority of requirements from different viewpoints changes during the development process The business and technical environment of the system changes during its development Enduring and Volatile Requirements Enduring requirements Stable requirements derived from the core activity of the customer organization E g a hospital will always have doctors nurses etc May be derived from domain models Volatile requirements Requirements which change during development or when the system is in use E g requirements derived from the latest health care policy Classification of Requirements e Mutable requirements those that change due to changes in the system s environment e Emergent requirements those that emerge as understanding of the system develops e Consequential requirements those that result from the introduction of the system e Compatibility requirements those that depend on other systems or organizational processes Requirements Management Planning During requirements management planning you must decide on e Requirements identification how requirements will be individually identified e A change manag
75. OCOMO 2 levels e COCOMO 2 isa 3 level model that allows increasingly detailed estimates to be prepared as development progresses Early prototyping level Estimates based on object points and a simple formula is used for effort estimation e Early design level Estimates based on function points that are then translated to LOC e Post architecture level Estimates based on lines of source code Early Prototyping Level Supports prototyping projects and projects where there is extensive reuse e Based on standard estimates of developer productivity in object points month e Takes CASE tool use into account e Formula is PM NOP 1 reuse 100 PROD PM is the effort in person months NOP is the number of object points and PROD is the productivity Object Point Productivity Developer s Very low Low Nominal High Veryhigh experience and capability ICASE maturity and Verylow Low Nominal High Veryhigh capability PROD NOP month 4 7 13 25 50 Early Design Level e Estimates can be made after the requirements have been agreed e Based on standard formula for algorithmic models PM A SizeB M PMm where M PERS RCPX RUSE PDIF PREX FCIL SCED PMm ASLOC AT 100 ATPROD A 2 5 in initial calibration Size in KLOC B varies from 1 1 to 1 24 depending on novelty of the project development flexibility risk manage ment approaches and the process maturity Multiplie
76. Process e Risk identification identify project product and business risks e Risk analysis assess the likelihood and consequences of these risks e Risk planning draw up plans to avoid or minimise the effects of the risk e Risk monitoring monitor the risks throughout the project Risk Identification e Technology risks e People risks e Organisational risks e Requirements risks e Estimation risks Taxonomy based on Source Risks and Risk Types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected Software components which should be reused contain defects which limit their functionality People It is impossible to recruit staff with the skills required Key staff are ill and unavailable at critical times Required training for staff is not available Organisational The organisation is restructured so that different management are responsible for the project Organisational financial problems force reductions in the project budget Tools The code generated by CASE tools is inefficient CASE tools cannot be integrated Requirements Changes to requirements which require major design rework are proposed Customers fail to understand the impact of requirements changes Estimation The time required to develop the software is underestimated The rate of defect repair is underestimated The size o
77. SE systems e May be translated into either a sequential or parallel design In a sequential design processing elements are functions or procedures in a parallel design processing elements are tasks or processes Payroll System DFD Eimplayee Tax duetin SS PRSE record number tax office rates Decoded Pension Read employee employer Vaid deduction SS number Print pay slip Net payment bank account info Write bank Bank transaction transactions Write social Social security data security data record employee record Validate employee data Empoyee data PRINTER deductions Pay information Read monthly pay data Monthly pay data Tax tables Social security deduction SS number Payroll Batch Processing The functions on the left of the DFD are input functions Read employee record Read monthly pay data Validate employee data The central function Compute salary carries out the processing The functions to the right are output functions Write tax transaction Write pension data Print payslip Write bank transaction and Write social security data Transaction Processing A bank ATM system is an example of a transaction processing system e Transactions are stateless in that they do not rely on the result of previous transactions Therefore a fu
78. Software engineering is an engineering discipline which is concerned with all aspects of software production Software products consist of developed programs and associ ated documentation Essential product attributes are maintainability dependability efficiency and usability The software process consists of activities which are involved in developing software products Basic activities are software specification development validation and evolution Methods are organised ways of producing software They include suggestions for the process to be followed the notations to be used and rules governing the system descrip tions which are produced and design guidelines CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams checking diagram consistency and keeping track of program tests which have been run Software engineers have responsibilities to the engineering profession and society They should not simply be concerned with technical issues Professional societies publish codes of conduct which set out the standards of behaviour expected of their members Activity What are the four important attributes which all software products have Suggest four attributes which may be significant ONIMSAANIDON A AYVMLIOS Activity What are the four important attributes which all software products should have Suggest four other attributes whi
79. State Description Waiting The oven is waiting for input The display shows the current time Half power The oven power is set to 300 watts The display shows Half power Full power The oven power is set to 600 watts The display shows Full power Set time The cooking time is set to the user s input value The display shows the cooking time selected and is updated as the time is set Disabled Oven operation is disabled for safety Interior oven light is on Display shows Not ready Enabled Oven operation is enabled Interior oven light is off Display shows Ready to cook Operation Oven in operation Interior oven light is on Display shows the timer countdown On completion of cooking the buzzer is sounded for 5 seconds Oven light is on Display shows Cooking complete while buzzer is sounding 37 Microwave Oven Stimuli Stimulus Description Half power The user has pressed the half power button Full power The user has pressed the full power button Timer The user has pressed one of the timer buttons Number The user has pressed a numeric key Door open The oven door switch is not closed Door closed The oven door switch is closed Start The user has pressed the start button Cancel The user has pressed the cancel button State Charts e Allow the decomposition of a model into sub models see following slide e A brief description of the actions is included following the
80. V amp V Software testing executing an implementation of the software to examine outputs and operational behaviour dynamic V amp V Static verification Formal specification Requirements High level specification design Dynamic validation Program Testing e Defect testing Tests designed to discover system defects Sometimes referred to as coverage testing Covered after Proofs of Correctness e Statistical testing Tests designed to assess system reliability and performance under operational conditions Makes use of an operational profile V amp V Goals Verification and validation should establish confidence that the software is fit for purpose e This does NOT usually mean that the software must be completely free of defects The level of confidence required depends on at least three factors Factors Affecting Level of Confidence Required 1 Software function purpose Safety critical systems require a much higher level of confidence than demonstration of concept prototypes 2 User expectations Users may tolerate shortcomings when the benefits of use are high 3 Marketing environment G etting a product to market early may be more important than finding additional defects V amp V Versus Debugging e V amp V and debugging are distinct processes V amp V is concemed with establishing the existence of defects in a program Debugging is concerned with locating and
81. ach with different periods the time between executions execution times and deadlines the time by which processing must be completed The real time clock ticks periodically and each tick causes an interrupt which schedules the process manager for periodic processes e The process manager selects a process which is ready for execution Process Management Concerned with managing the set of concurrent processes e Periodic processes are executed at pre specified time intervals The executive uses the real time clock to determine when to execute a process e Process period time between executions e Process deadline the time by which processing must be complete RTE Process Management and processor Process Sw itching The scheduler chooses the next process to be executed by the processor This depends on a scheduling strategy which may take the process priority into account The resource manager allocates memory and a processor for the process to be executed The despatcher takes the process from ready list loads it onto a processor and starts execution Choose process for execution Scheduling Strategies Non pre emptive scheduling Once a process has been scheduled for execution it runs to completion or until it is blocked for some reason e g waiting for I O e Pre emptive scheduling The execution of executing processes may be stopped if a higher priority process requires service Scheduling
82. ality audits Trainin Servicing Statistical techniques ISO 9000 Certification e Quality standards and procedures should be documented in an organisational quality manual e External body may certify that an organisation s quality manual conforms to ISO 9000 standards Customers are increasingly demanding that suppliers are ISO 9000 certified 120 ISO 9000 and Quality Management ISO 9000 quality models instantiated as documents Organization quality manual Project 2 quality plan Organization quality process instantiated as Project quality management Project 1 Project 3 quality plan quality plan Supports Quality Assurance and Standards e Standards are the key to effective quality management e They may be international national and organizational or project standards Product standards define characteristics that all components should exhibit e g a common programming style e Process standards define how the software process should be enacted Importance of Standards Encapsulation of best practice avoids repetition of past mistakes e Framework for quality assurance process it involves checking standard compliance e Provide continuity new staff can understand the organisation by understand the standards applied Product and Process Standards Process standards Design review conduct Submission of documents to CM Version release process Product standa
83. ality into account e Productivity may generally be increased at the cost of quality e It is not clear how productivity quality metrics are related e If change is constant then an approach based on counting lines of code is not meaningful 113 Estimation Techniques e There is no simple way to make an accurate estimate of the effort required to develop a software system Initial estimates are based on inadequate information in a user requirements definition The software may run on unfamiliar computers or use new technology The people in the project may be unknown e Project cost estimates may be self fulfilling The estimate defines the budget and the product is adjusted to meet the budget e Algorithmic cost modelling e Expert judgement e Estimation by analogy e Parkinson s Law e Pricing to win Algorithmic Code Modelling e A formulaic approach based on historical cost information and which is generally based on the size of the software Expert Judgement e One or more experts in both software development and the application domain use their experience to predict software costs Process iterates until some consensus is reached e Advantages Relatively cheap estimation method Can be accurate if experts have direct experience of similar systems Disadvantages Very inaccurate if there are no experts Estimation by Analogy The cost of a project is computed by comparing the project to a similar project in the
84. anagement middleware can translate text interfaces to graphical interfaces Desktop PC clients with GU interface Screen descriptions Legacy system Application services Screen management middleware Database User interface UI Migration Strategies Strategy Advantages Disadvantages Implementation Access to all UI functions sono Platform dependent using the window real restrictions onUI design May be more difficult to achieve managenent Better Ul performance interface corsistency system Implementation Platform independert Potertially poaer UI using aweb Lower training costs due to wer performance browser familiarity with the WWW Interface design is constrained Easier to achieve interface by the facilities provided by web corsistency browsers Key Points Software change strategies include software maintenance architectural evolution and software re engineering Lehman s Laws are invariant relationships that affect the evolution of a software system e Maintenance types are Maintenance for repair Maintenance for a new operating environment Maintenance to implement new requirements The costs of software change usually exceed the costs of software development e Factors influencing maintenance costs include staff stability the nature of the development contract skill shortages and degraded system structure e Architectural evolution is concemed with evolving centralised to distributed ar
85. angerous condition The output displays show the dose computed and a warning message The alarm is activated if blood sugar is very low this indicates that the user should eat something to increase his blood sugar level DIS PLAY Alnsulin_Pump conversion Note conflict with i insulin low msg l Nat_to_s tring dose A reading lt 3 gt Sugar low v reading gt 20 gt display1 Sugar high v reading 3 and reading 30 display1 OK ALARM Alnsulin_ Pump re ading lt 2 v reading gt 30 alarm on AND reading 3 Areading 30 alarm oft Schema Consistency e It is important that schemas be consistent Inconsistency suggests a problem with system requirements The INSULIN PUMP schema and the DISPLAY are inconsistent display1 shows a warning message about the insulin reservoir INSULIN PUMP display1 Shows the state of the blood sugar DISPLAY e This must be resolved before implementation of the system Secification Via Pre and Post conditions e Predicates that when considered together reflect a program s intended functional behavior are defined over its state variables e Pre condition expresses constraints on program variables before program execution An implementer may assume these will hold BEFORE program execution Post condition expresses conditions relationships among program variables after execution These capture any obligat
86. anuals etc e The user guidance system should be integrated with the user interface to help users when they need information about the system or when they make some kind of error The help and message system should if possible be integrated Help and Message System Application Help Error message interface system Message presentation sys tem Help frames Error Messages Error message design is critically important Poor error messages can mean that a user rejects rather than accepts a system e Messages should be polite concise consistent and constructive The background and experience of users should be the determining factor in message design Error message texts Design Factors in Message Wording Context The user guidance system should be aware of what the user is doing and should adjust the output message to the current context As users become familiar with a system by long meaningful messages they become irritated However beginners find it the problem types of message Experience difficult to understand short terse statements of The user guidance system should provide both _and allow the user to control message conciseness Skill level Messages should be tailored to experience Messages for the different classes expressed in different ways depending on the user s skills as well as their of user may be the terminology which is familiar to the reade
87. any limitations on their use e Defines the process of tool use Defines the CM database used to record configuration information e May include information such as the CM of external software process auditing etc Configuration Item Identification e Large projects typically produce thousands of documents which must be uniquely identified Some of these documents must be maintained for the lifetime of the software Document naming scheme should be defined so that related documents have related names e A hierarchical scheme with multi level names is probably the most flexible approach Configuration Hierarchy PCL TOOLS COMPILE BIND MA KE GEN am STRUC TUR ES am SO DISPLAY QUERY a AS T INTERFACE FORM IO FORM SPECS de OBJECTS CODE TESTS The Configuration Database e All CM information should be maintained in a configuration database e This should allow queries about configurations to be answered Who has a particular system version What platform is required for a particular version What versions are affected by a change to component X How many reported faults in version T e The CM database should preferably be linked to the software being managed Cm Database Implementation e May be part of an integrated environment to support software development The CM database and the managed documents are all maintained on the same system CASE tools may be integrated with this so that there
88. arallel working on different versions Delta based Versioning ea rsion m Creation date Ea rsion G rsion oa Ea 0 T G 1 aA 1 2 System Building Building a large system is computationally expensive and may take several hours e Hundreds of files may be involved e System building tools may provide A dependency specification language and interpreter Tool selection and instantiation support Distributed compilation Derived object management Component Dependencies Key Points e Configuration management is the management of system change to software products e A formal document naming scheme should be established and documents should be managed in a database e The configuration database should record information about changes and change requests e A consistent scheme of version identification should be established using version numbers attributes or change sets e System releases include executable code data configuration files and documentation e System building involves assembling components into a system e CASE tools are available to support all CM activities CASE tools may be stand alone tools or may be integrated systems which integrate support for version management system building and change management 153 ONIMSANIDONA AYVMLIOS Activity Explain why you should not use the title of a document to identify the document in a configuration management system Suggest a standar
89. ardware platform e Personnel attributes Multipliers that take the experience and capabilities of the people working on the project into account e Project attributes Concerned with the particular characteristics of the software development project Project Cost Drivers Product attributes RELY Required system DATA Size of database used reliability CPLX Complexity of system RUSE Required percentage of modules reusable components DOCU Extent of documentation required Computer attributes TIME Execution time STOR Memory constraints constraints PVOL Volatility of development platform Personnel attributes ACAP Capability of project PCAP Programmer capability analysts PCON Personnel continuity AEXP Analyst experience in project domain PEXP Programmer experience LTEX Language and tool experience in project domain Project attributes TOOL Use of software tools SITE Extent of multi site working and quality of site communications SCED Development schedule compression Project Planning e Algorithmic cost models provide a basis for project planning as they allow alternative strategies to be compared e Embedded spacecraft system Must be reliable Must minimise weight number of chips Multipliers on reliability and computer constraints gt 1 e Cost components Target hardware Development platform Effort required Management Options A Use existing hardware development system and development team
90. as C allow efficient programs to be written but do not have constructs to support concurrency or shared resource management Ada as a language designed to support real time systems design so includes a general purpose concurrency mechanism Java As A Real time Language e Java supports lightweight concurrency threads and synchronized methods and can be used for some soft real time systems e Java 2 0 is not suitable for hard RT programming or programming where precise control of timing is required Not possible to specify thread execution time Uncontrollable garbage collection Not possible to discover queue sizes for shared resources Variable virtual machine implementation Not possible to do space or timing analysis Real time Executives Real time executives are specialised operating systems which manage the processes in the RTS Responsible for process management and resource processor and memory allocation May be based on a standard RTE kernel which is used unchanged or modified for a particular application Does not include facilities such as file management Executive Components Real time clock Provides information for process scheduling Interrupt handler Manages aperiodic requests for service Scheduler Chooses the next process to be run Resource manager Allocates memory and processor resources 75 e Despatcher Starts process execution Non stop System Components e Configuration
91. ase models aggregation models generalisation inheritance models etc Subsystem Models e In the UML these are shown using packages an encapsulation construct e This is a logical model the actual organization of objects in the system as implemented may be different Weather Station Subsystems Annotations subsystem Interface Comms Controller WeatherStation subsystem Instruments Air thermometer subsystem Data collection WeatherData Status RainGauge Barometer Ground thermometer 70 Sequence Models Objects are arranged horizontally across the top Time is represented vertically models are read top to bottom e Interactions are represented by labelled arrows different styles of arrows represent different types of interaction e A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system Data collection sequence Weather Station State Machine Model Operation calibrate Calibrating Lee calibration OK Transmitting cao aries test complete collection done Collecting weather summary complete A 5 Object Interface Specification Designers should avoid revealing data representation information in their interface design operations access and update data Objects may have several logical interfaces which are viewpoints on the metho
92. ay be critical to the operation of a business Activity Suggest three reasons why software systems become more difficult to understand when different people are involved in changing these systems Activity What difficulties are likely to arise when different components of a legacy system are implemented in different programming languages Activity Why is it necessary to use a teleprocessing monitor when requests to update data in a system come form a number of different terminals How do modern client server systems reduce the load on the teleprocessing monitor 136 Activity Most legacy systems use a function oriented approach to design Explain why this approach to design may be more appropriate for these systems than an object oriented design strategy Activity Under what circumstances might an organization decide to scrap a system when the system assessment suggests that it is of high quality and high business value Activity Suggest 10 questions that might be put to end users of a system when carrying out a business process assessment Activity Explain why problems with support software might mean that an organization has to replaces its legacy systems 137 ONIMAANIDN A AYVMLIOS ONIMAANIDON A JAVMI OS Activity The management of an organization has asked you to carry out a system assessment and has suggested to you that they would like the results of that assessment to show that the system is obsolete
93. ber of values Equivalence class boundaries Elements lt Mid W Elements gt Mid Mid point Binary Search Test Cases Input array T Key Key Output Found L 17 17 true 1 17 0 false 17 21 23 29 17 true 1 9 16 18 30 31 41 45 45 true 7 17 18 21 23 29 38 41 23 true 4 17 18 21 23 29 33 38 21 true 3 12 18 21 23 32 23 true 4 21 23 29 33 38 25 false Path Testing e The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control e Statements with conditions are therefore nodes in the flow graph Program Flow Graphs Describes the program control flow Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition node e Used as a basis for computing the cyclomatic complexity Cyclomatic complexity Number of edges Number of nodes 2 Cyclomatic Complexity The number of tests to test all control statements equals the cyclomatic complexity Cyclomatic complexity equals number of conditions in a program e Useful if used with care Does not imply adequacy of testing e Although all paths are executed all combinations of paths are not executed while bottom lt to
94. bjects or ADTs Analyse common data areas to identify logical abstractions Create an ADT or object for these abstractions Use a browser to find all data references and replace with reference to the data abstraction Data Abstraction Recovery e Analyse common data areas to identify logical abstractions e Create an abstract data type or object class for each of these abstractions e Provide functions to access and update each field of the data abstraction e Use a program browser to find calls to these data abstractions and replace these with the new defined functions Data Re engineering e Involves analysing and reorganising the data structures and sometimes the data values in a program e May be part of the process of migrating from a file based system to a DBMS based system or changing from one DBMS to another e Objective is to create a managed data environment 145 Approaches to Data Re engineering Approach Description Data cleanup The data records and values are analysed to improve their quality Duplicates are removed redundant information is deleted and a consistent format applied to all records This should not normally require any associated program changes Data extension In this case the data and associated programs are re engineered to remove limits on the data processing This may require changes to programs to increase field lengths modify upper limits on the tables etc The data itself may then ha
95. bstract or detailed and mathematical e The hardest single part of building a software system is deciding precisely what to build No other part of the conceptual work is as difficult No other part of the work so cripples the resulting system if done wrong No other part is more difficult to rectify later Fred Brooks No Silver Bullet Why is Requirements Engineering So Hard e Difficulty of anticipation e Unknown or conflicting requirements priorities e Conflicts between users and procurers e Fragmented nature of requirements e Complexity number of distinct requirements e Some analogies Working a dynamically changing jigsaw puzzle Blind men describing an elephant Different medical specialists describing an ill patient Types of Requirements e Requirements range from being high level and abstract to detailed and mathematical e This is inevitable as requirements may serve multiple uses May be the basis for a bid for a contract must be open to interpretation May be the basis for the contract itself must be defined in detail May be the basis for design and implementation must bridge requirements engineering and design activities e User requirements statements in natural language plus diagrams of system services and constraints Written primarily for customers e System requirements structured document setting out detailed descriptions of services and constraints precisely May serve as a contract
96. cess improvement To explain how software process factors influence software quality and productivity To introduce the SEI Capability Maturity Model and to explain why it is influential To discuss the applicability of that model To explain why CMM based improvement is not universally applicable Topics Covered e Process and product quality e Process analysis and modelling e Process measurement The SEI process maturity model e Process classification Process Improvement Understanding existing processes e Introducing process changes to achieve organisational objectives which are usually focused on quality improvement cost reduction and schedule acceleration e Most process improvement work so far has focused on defect reduction This reflects the increasing attention paid by industry to quality However other process attributes can be the focus of improvement Process Attributes Process characteristic Description Understandability To what extent is the process explicitly defined and how easy is it to understand the process definition Visibility Do the process activities culminate in clear results so that the progress of the process is externally visible Supportability To what extent can the process activities be supported by CASE tools Acceptability Is the defined process acceptable to and usable by the engineers responsible for producing the software product Reliabil
97. ch may be significant Activity Explain why system testing costs are particularly high for generic software products which are sold to a very wide market Activity Software engineering methods only became widely used when CASE technology became available to support them Suggest five types of method support which can be provided by CASE tools Activity Apart from the challenges of legacy systems heterogeneity and rapid delivery identify other problems and challenges that software engineering is likely to face in the 21 century Notes SOFTWARE ENGINEERING LESSON 2 AND 3 SOFTWARE PROCESSES Coherent Sets of Activities For Specifying Designing Implementing And Testing Software Systems Objectives e To introduce software process models e To describe a number of generic process models and when they may be used e To outline lower level process models for requirements engineering software development testing and evolution e To introduce CASE technology to support software process activities Topics Covered e Software process models e Process iteration e Software specification e Software design and implementation e Software verification amp validation e Software evolution Automated process support The Software Process A structured set of activities required to develop a software system e Specification e Design e Validation verification e Evolution A software process model is an abs
98. ch a profession 60 LESSON17 AND 18 DISTRIBUTED SYSTEMS ARCHITECTURES Architectural Design for Software That Executes on More Than One Processor Objectives To explain the advantages and disadvantages of distributed systems architectures To describe different approaches to the development of client server systems To explain the differences between client server and distributed object architectures To describe object request brokers and the principles underlying the CORBA standards Topics Covered Multiprocessing systems Distributed systems architectures Client server architectures Distributed object architectures CORBA Common O bject Request Broker Architecture Multiprocessor Architectures System composed of multiple processes which may or may not execute on different processors Distribution of process to processor may be pre ordered or may be under the control of a dispatcher A Multiprocessor Traffic Control System gr Q gE Traffic flow processor Display process Sensor processor Traffic light control gl 3 processor Light control process Traffic lights Sensor control process Traffic flow sensors and cameras Operator consoles Types of Multiprocessing Systems Personal systems that are not distributed and that are designed to run on a personal computer or workstation word processors E
99. chitectures e A distributed user interface can be supported using screen management middleware Activity Explain why a software system which is used in a real world environment must change or become progressively less useful 142 Activity Explain the difficulties of measuring program maintainability Suggest why you should use several different complexity metrics when trying to assess the maintainability of a program Activity As a software project manager in a company that specializes in the development of software for the offshore oil industry you have been given the task of discovering those factors which affect the maintainability of the particular systems which are developed by your company Suggest how you might set up a programme to analyze the maintenance process to discover appropriate maintainability metrics for your company Activity Two major international banks with different customer information databases merge and decide that they need to provide access to all customer information form all bank branches Giving reasons for your answer suggest the most appropriate strategy for providing access to these systems and briefly discuss how the solution might be implemented Activity Do software engineers have a professional responsibility to produce maintainable code even if this is not explicitly re quested by their employer 143 ONIYSANIDONA AYVMLIOS LESSON 38 SOFTWARE RE ENGINEERING Reorganising a
100. cking the software development process to ensure that procedures and standards are being followed Two approaches to quality control Quality reviews Automated software assessment and software measurement Quality Reviews The principal method of validating the quality of a process or of a product Group examined part or all of a process or system and its documentation to find potential problems e There are different types of review with different objectives Inspections for defect removal product Reviews for progress assessment product and process Quality reviews product and standards Types of Review Review type Principal purpose Design or program To detect detailed errors in the design or code and to check whether standards have been followed The review should be driven by a checklist of possible errors Progress reviews To provide information for management about the overall progress of the project This is both a process and a product review and is concerned with costs plans and schedules To carry out a technical analysis of product components or documentation to find faults or mismatches between the specification and the design code or documentation It may also be concerned with broader quality issues such as adherence to standards and other quality attributes inspections Quality reviews Quality Reviews A group of people carefully examine part or all of a software system and i
101. concerned with realising an OOD using an OO programming language such as Java or C Objects and Object Classes e Objects are entities with state and a defined set of operations on that state State is represented as a set of object attributes Operations provide services to other objects when requested e Object classes are templates for objects An object class definition includes declarations of all attributes and operations associated with an object of that class They may inherit attributes and services from other object Classes The Unified Modeling Language e Several different notations for OOD were proposed in the 1980s and 1990s Booch Rumbaugh Jacobson Coad amp Yourdon Wirfs UML is an integration of these notations e It describes a number of different models that may be produced during OO analysis and design user view structural view behavioural view implementation view Employee Object Class UML Employee name string address string dateOfBirth Date employeeNo integer socialSecurityNo string department Dept manager Employee salary integer status current left retired taxC ode integer join leave retire changeDetails 67 Object Communication e Conceptually objects communicate by message passing e Messages include The name of the service requested A copy of the information required to carry out the service and the name of a
102. cture the three layers are distributed between a server processor and a set of clients e Three tier C S architecture the layers are distributed among two server processes processors and a set of clients e Multi tier C S architectures the layers are distributed among multiple server processes processors each associated with a separate database for example and a set of clients Two tier Architectures Thin and Fat Clients e Thin client model the application logic and data management are implemented on the server the client only handles the user interface e Fat client model the server is only responsible for data management the client handles the application logic and the user interface Thin and Fat Clients Presentation Server Data management Thin client model Application processing Presentation Application processing Server Fat client model Data management Thin client Model e Often used when centralized legacy systems evolve to a C S architecture the user interface is migrated to workstations or terminals and the legacy system acts as a server e Places a heavy processing load on both the server and the network this is wasteful when clients are powerful workstations Fat client Model e More processing is delegated to the client as the application logic is executed locally But system management is more complex especially when application function changes and
103. d Modelling Language e Devised by the developers of widely used object oriented analysis and design methods Has become an effective standard for object oriented modelling e Notation Object classes are rectangles with the name at the top attributes in the middle section and operations in the bottom section Relationships between object classes known as associations are shown as lines linking objects Inheritance is referred to as generalisation and is shown upwards rather than downwards in a hierarchy Library Class Hierarchy Catalogue number Acquisition date Number of copies Acquire Catalogue Dispose Issue Return Published item Title Publisher Title Medium aaa Compa Author Year Director Edition Tue Date of release Version i Distributor Platform Publication date ISBN User Class Hierarchy Name Address Phone Registration Register De register Affiliation Borrower Items onloan Max loans p AN Staff Department Major subject Department phone Home address Multiple Inheritance e Rather than inheriting the attributes and services from a single parent class a system which supports multiple inheritance allows object classes to inherit from several super classes e Can lead to semantic conflicts where attributes services with the same name in diff
104. d as nodes Links Relation 8 12 1998 are typed and may be named Each label has a name which name identifies the type of label The name Attribute 8 12 1998 label must be unique within the set of label types used in a design Each node has a name which must be name unique within a design The name Attribute 15 11 1998 node may be up to 64 characters long Object Models e Object models describe the system in terms of object classes e An object class is an abstraction over a set of objects with common attributes and the services operations provided by each object Various object models may be produced Inheritance models 38 Aggregation models Interaction models Natural ways of reflecting the real world entities manipulated by the system More abstract entities are more difficult to model using this approach e Object class identification is recognised as a difficult process requiring a deep understanding of the application domain e Object classes reflecting domain entities are reusable across systems Inheritance Models e Organise the domain object classes into a hierarchy e Classes at the top of the hierarchy reflect the common features of all classes Object classes inherit their attributes and services from one or more super classes These may then be specialised as necessary e Class hierarchy design is a difficult process if duplication in different branches is to be avoided The Unifie
105. d for a document identification scheme that may be used for all projects in an organization Activity Using the entity relational or object oriented approach design a model of a configuration database which records information about system components versions releases and changes Some requirements for the data model are as follows e It should be possible to retrieve all versions or a single identified version of a component e It should be possible to retrieve the latest version of a component e It should be possible to find out which change requests have been implemented by a particular version of a system e It should be possible to discover which versions of components are included in a specified version of a system e It should be possible to retrieve a particular release of a system according to either the release date or the customers to whom the release was delivered Activity Using a data flow diagram D escribe a change management procedure which might be used in a large organization concerned with developing software foe external clients Changes may be suggested form either external or internal sources Activity Describe the difficulties which can be encountered in system building Suggest particular problems that might arise when a system is built on a host computer for some target machine 154 Activity A common problem with system building occurs when physical file names are incorporated in system
106. d in all requirements analyses In your work you find that this method cannot represent social factors which are significant in the system you are analyzing You point out to your manager who makes clear that the standard should be followed Discuss what you should do in such a situations Notes 35 ONIMAANIDN A AYVWMLIOS LESSON 10 AND 11 SYSTEM MODELS Abstract Descriptions of Systems Whose Requirements are Being Analysed Objectives e To explain why the context of a system should be modelled as part of the RE process To describe behavioural modelling data modelling and object modelling e To introduce some of the notations used in the Unified Modelling Language UML To show how CASE workbenches support system modelling Topics Covered Context models e Behavioural models e Data models e Object models e CASE workbenches System Modelling e System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers Different models present the system from different perspectives External perspective showing the system s context or environ ment Behavioural perspective showing the behaviour of the system Structural perspective showing the system or data architecture Structured Methods e Structured methods incorporate system modelling as an inherent part of the method e Methods define a set of models a process for deriving these
107. d record in outline the change made the rationale for the change who made the change and when it was implemented e May be included as a comment in code If a standard prologue style is used for the derivation history tools can process this automatically Component Header Information PROTEUS project ESP RIT 6087 Ht PCL TOOLS EDIT FORMS DISP LAY AS T INTERF ACE I Object PCL Tool Desc Author G Dean Creation date 10th November 1998 II Lancaster University 1998 Modification his tory Version 1 0 J Jones 1 1 G Dean Modifier Date Change Reason 1 12 1998 Add header Submitted to CM 9 4 1999 New field Change req R07 99 Version and Release Management e Invent identification scheme for system versions e Plan when new system version is to be produced e Ensure that version management procedures and tools are properly applied e Plan and distribute new system releases Versions Variants Releases e Version An instance of a system which is functionally distinct in some way from other system instances e Variant An instance of a system which is functionally identical but non functionally distinct from other instances of a system e Release An instance of a system which is distributed to users outside of the development team Version Identification e Procedures for version identification should define an unambiguous way of identifying component versions e Three basic techniqu
108. del is a framework for improving the capabilities of staff in an organisation Activity What is the difference between syntactic and semantic knowl edge Form your own experience suggest a number of instances of each of these types of knowledge Activity As a training manager you are responsible for the initial programming language training of a new graduate intake to your company whose business is the development of defense aerospace systems The principal programming language used is Ada which was designed for defense systems programming The trainees may be computer science graduates engineers or physical scientists Some but not all of the trainees have previous programming experience none have previous experience in Ada Explain how you would structure the programming t4aining for this group of graduates Activity What factors should be taken into account when selecting staff to work on a software development project Activity Explain why keeping all members of a group informed about progress and technical decisions in a project can improve group cohesiveness 109 ONIYSANIDONA AYVMLIOS ONIMSAANIDNA AYVMLIOS Activity Explain what you understand by groupthink D escribe the dangers of this phenomenon and explain how it might be avoided Activity You are a programming manager who has been given the task of rescuing a project that is critical to the success of the company Senior management have given you
109. deliver an acceptable working development projects system to end users J e To discuss evolutionary and throw away prototyping Experimental prototyping to evaluate proposed solutions for gt To introduce three rapid prototyping techniques feasibility performance etc E High level language development Simulation Prototyping and Scenarios Z Database programming and e What are the differences between prototyping and Component reuse simulation m To explain the need for user interface prototyping Topics Covered Prototyping in the software process e Rapid prototyping techniques e User interface prototyping What is Prototyping Some traditional features An iterative process emphasizing Rapid development Evaluative use e What is the connection between simulation models Feedback and prototypes scenarios Modification Simulation models are automatic scenario generators Learning based on feedback Prototypes facilitate manual scenario generation Consideration of alternatives Prototyping Benefits Concreteness a real system is developed and presented to real Misunderstandings exposed users e Difficult to use or confusing services identified Boundary between prototyping and normal system e Missing services detected development blurs when an evolutionary e g agile e Incomplete and or inconsistent requirements found by development approach is used analysts as prototype is being developed Can demo Us
110. deliverable documents shall conform to the process and deliverables defined in X YZCo SP STAN 95 e External requirement 7 6 5 the system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system Goals Versus Requirements e General goals such as system should be user friendly or system should have fast response time are not verifiable e Goals should be translated into quantitative requirements that can be objectively tested Examples e A system goal The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized e A verifiable non functional requirement Experienced controllers shall be able to use all the system functions after a total of two hours training After this training the average number of errors made by experienced users shall not exceed two per day Requirements Measures Measure Processed transactions second User Event response time Screen refresh time Size K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Ease of use Reliability Probability of unavailability Rate of failure occurrence Availabilit Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Robustness Portability
111. dressed in interactive systems design How should information from the user be provided to the computer system How should information from the computer system be presented to the user User interaction and information presentation may be integrated through a coherent framework such as a user interface metaphor Interaction Styles Direct manipulation e Menu selection e Form fill in Command language Natural language Direct Manipulation Advantages Users feel in control of the computer and are less likely to be intimidated by it User learning time is relatively short e Users get immediate feedback on their actions so mistakes can be quickly detected and corrected Direct Manipulation Problems e The derivation of an appropriate information space model can be very difficult Given that users have a large information space what facilities for navigating around that space should be provided Direct manipulation interfaces can be complex to program and make heavy demands on the computer system Control Panel Interface Title JSD example O aia Method JSD Type I Network Units cm gt Selection Process Reduce J Full gt Ea Ed Ea el A Menu Systems e Users make a selection from a list of possibilities presented to them by the system e The selection may be made by pointing and clicking with a mouse using cursor keys or by typing the name of the selection
112. ds provided supported directly in Java e The UML uses class diagrams for interface specification but pseudocode may also be used Design Evolution Hiding information in objects means that changes made to an object do not affect other objects in an unpredictable way e Assume pollution monitoring facilities are to be added to weather stations e Pollution readings are transmitted with weather data Changes Required e Add an object class called Air quality as part of Weather Station e Add an operation reportAirQuality to WeatherStation Modify the control software to collect pollution readings e Add objects representing pollution monitoring instruments Pollution Monitoring WeatherStation reportW eather reportAirQuality calibrate instruments test collect startup instrum ents sum marise shutdown instruments Air quality NO Data smokeData benzeneData Pollution monitoring instruments Key Points OOD results in design components with their own private state and operations e Objects should have constructor and inspection operations They provide services to other objects e Objects may be implemented sequentially or concurrently The Unified Modeling Language provides different notations for defining different object models e A range of different models may be produced during an object oriented design process These include static and dynamic system models Object int
113. e constraints that are set by the organization developing the software Softw are Management Distinctions e The product is intangible e The product is uniquely flexible e Software engineering is not recognized as an engineering discipline with the same status as mechanical electrical engineering etc e The software development process is not standardized e Many software projects are one off projects Management Activities e Proposal writing to fund new projects e Project planning and scheduling e Project costing and preparing bids e Project monitoring and reviews e Personnel selection and evaluation e Report writing and presentations e Attending lots and lots of meetings Management Commonalities e These activities are not peculiar to software management e Many techniques of engineering project management are equally applicable to software project management e Technically complex engineering systems tend to suffer from most of the same problems as software systems Project Staffing e May not be possible to appoint the ideal people to work on a project Project budget may not allow for use of highly paid staff Those with appropriate skills experience may not be available An organization may wish to develop employee skills by assigning inexperienced staff e Managers have to work within these constraints especially when as is currently the case there is an international shortage of
114. e or constraints on development process e g use of a particular CASE toolset e Domain requirements functional or non functional requirements derived from application domain e g legal requirements or physical laws Examples of Functional Requirements e The user shall be able to search either all of the initial set of databases or select a subset from it e The system shall provide appropriate viewers for the user to read documents in the document store e Every order shall be allocated a unique identifier ORDER ID which the user shall be able to copy to the account s permanent storage area Requirements Imprecision e Problems arise when requirements are not precisely stated e Ambiguous requirements may be interpreted in different ways e Consider the term appropriate viewers User intention special purpose viewer for each different document type Developer interpretation provide a text viewer that shows the contents of the documents Product requirements Requirements Completeness and Consistency e In principle a requirements specification should be both complete and consistent Complete all required services and constraints are defined Consistent no conflicts or contradictions in the requirements e In practice this is nearly impossible Non functional Requirements e Define system attributes e g reliability response time and constraints e g MTTF e 5K transactions response time
115. e engineers shall adhere to the following Eight Principles Code of Ethics Principles 1 Public Software engineers shall act consistently with the public interest 2 Clients and Employer Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest 3 Product Software engineers shall ensure that their products and related modifications meet the highest professional standards possible 4 Judgment Software engineers shall maintain integrity and independence in their professional judgment 5 Management Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance 6 Profession Software engineers shall advance the integrity and reputation of the profession consistent with the public interest 7 Colleagues Software engineers shall be fair to and supportive of their colleagues 8 Self Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession Ethical Dilemmas Disagreement in principle with the policies of senior manage ment Your employer acts in an unethical way and releases a safety critical system without finishing the testing of the system Participation in the development of military weapons systems or nuclear systems Key Points
116. e name to be processed by building tools Dependencies between these are described to the building tools 152 e Mistakes can be made as users lose track of which objects are stored in which files e A system modelling language addresses this problem by using a logical rather than a physical system representation CASE Tools for Configuration Management e CM processes are standardised and involve applying pre defined procedures e Large amounts of data must be managed CASE tool support for CM is therefore essential e Mature CASE tools to support configuration management are available ranging from stand alone tools to integrated CM workbenches Change Management Tools e Change management is a procedural process so it can be modelled and integrated with a version management system e Change management tools Form editor to support processing the change request forms Workflow system to define who does what and to automate information transfer Change database that manages change proposals and is linked to a VM system Version Management Tools Version and release identification Systems assign identifiers automatically when a new version is submitted to the system e Storage management System stores the differences between versions rather than all the version code e Change history recording Record reasons for version creation e Independent development Only one version at a time may be checked out for change P
117. e process to another 36 Equipment Procurement Process Delivery note Equipment Checked i Delivery i note spec 1 spec ea Validate H Get cost 4 eee z specification J7 estimates QANAY equipment Spec supplier Order Installation Installation acceptance Blank order form Equipment g estimate Ji instructions spec Supplier list notification Supplier Find Choo se Install i database suppliers supplier equipment Order details Accept ddivered equipment Checked and signed order form Equipment details Equipment jg database Behavioural Models e Behavioural models are used to describe the overall behaviour of a system Two types of behavioural model are shown here D ata processing models that show how data is processed as it moves through the system State machine models that show the systems response to events Both of these models are required for a description of the system s behaviour Data processing Models Data flow diagrams are used to model the system s data processing These show the processing steps as data flows through a system e Intrinsic part of many analysis methods e Simple and intuitive notation that customers can understand e Show end to end processing of data Order Processing DFD Checked and Capa ed za ged Sendto signed order Oi ome fom ongim ole form supplier orde detai
118. e same time A robot floor cleaner which is intended to clean relatively clear spaces such as corridors The cleaner must be able to sense walls and other obstructions Activity Design an architecture for the above systems based on your choice of model Make reasonable assumptions about the system requirements Activity Explain why a call return model of control is not usually suitable for real time systems which control some process Activity Giving reasons for your answer suggest an appropriate control model for the following systems e A batch processing system which takes information about hours worked and pays rates and prints salary slips and bank credit transfer information e A set of software tools which are produced buy different vendors but which mist work together e A television controller which responds to signals form a remote control unit 59 ONIMSANIDONA 3AYVMLAIOS ONIMSAANIDON A JAVMI OS Notes Activity Discuss their advantages and disadvantages as far as disreputa bility is concerned of the data flow model and the object model Assume that both single machine and distributed versions of an application are required Activity Should there be a separate profession of software architect whose role is to work independently with a customer to design a software architecture This would then be implemented by some software company What might be the difficulties of establishing su
119. e systems Reuse oriented Development Based on systematic as opposed to serendipitous reuse of existing software units Units may be e Procedures or functions common for past 40 years e Components component based development e Core elements of an application application family e Entire applications COTS Commercial off the shelf systems May also be based on use of design patterns e Process stages e Reusable software analysis e Requirements modification e System design with reuse e Development and integration This approach is becoming more important but experience is Requirements Component Requirements System design specification analysis modification with reuse Development System and integration caidan Process Iteration For large systems requirements ALWAYS evolve in the course of a project Thus process iteration is ALWAYS part of the process Iteration can be incorporated in any of the generic process models Two other approaches that explicitly incorporate iteration e Incremental development e Spiral development Incremental Development Rather than deliver the system as a single unit the development and delivery is broken down into increments each of which incorporates part of the required functionality User requirements are prioritised and the highest priority requirements are included in early increments Once the development of an increment is started
120. easure reliability after development Clean Room Process Evaluation e Results in IBM and elsewhere have been very impressive with very few discovered faults in delivered systems e Independent assessment shows that the process is no more expensive than other approaches Not clear how this approach can be transferred to an environment with less skilled engineers Key Points Verification and validation are not the same Verification shows conformance with a specification validation shows conformance with customer s needs desires e Static verification techniques involve examination and analysis of software elements for error detection e Program inspections are very effective in discovering errors e The Clean room development process depends on formal specification static verification and statistical testing Activity Discuss the differences between verification and validation and explain why validations particularly difficult process Activity Explain why it is not necessary for a program to be completely free of defects before it is delivered to its customers To what extent can testing be used to validate that the program is fit for its purpose Activity Explain why program inspections are an effective technique for discovering errors in a program What types of error are unlikely to be discovered through inspections Activity Explain why an organization with a competitive elitist culture would probably
121. ectives To introduce the quality management process and key quality management activities To explain the role of standards in quality management To explain the concept of a software metric predictor metrics and control metrics e To explain how measurement may be used in assessing software quality Topics Covered e Quality assurance and standards e Quality planning e Quality control Software measurement and metrics Softw are Quality Management Concerned with ensuring that the required level of quality is achieved in a software product e Involves defining appropriate quality standards and procedures and ensuring that these are followed e Should aim to develop a quality culture where quality is seen as everyone s responsibility What is Quality e Quality simplistically means that a product should meet its specification This is problematical for software systems Tension between customer quality requirements efficiency reliability etc and developer quality requirements maintainabil ity reusability etc Some quality requirements are difficult to specify in an unam biguous way Software specifications are usually incomplete and often inconsistent The Quality Compromise We cannot wait for specifications to improve before paying attention to quality management Must put procedures into place to improve quality in spite of imperfect specification e Quality management is the
122. ed in Chapter 20 Length of This is a measure of the average length of distinct identifiers in a identifiers program The longer the identifiers the more likely they are to be meaningful and hence the more understandable the program Depth of This is a measure of the depth of nesting of if statements in a conditional nesting program Deeply nested if statements are hard to understand and are potentially error prone Fog index This is a measure of the average length of words and sentences in documents The higher the value for the Fog index the more difficult the document may be to understand Object oriented Metrics Object Description oriented metric Depth of This represents the number of discrete levels in the inheritance tree where inheritance sub classes inherit attributes and operations methods from super classes tree The deeper the inheritance tree the more complex the design as potentially many different object classes have to be understood to understand the object classes at the leaves of the tree Method fan This is directly related to fan in and fan out as described above and means in fan out essentially the same thing However it may be appropriate to make a distinction between calls from other methods within the object and calls from external methods Weighted This is the number of methods included in a class weighted by the methods per complexity of each method Therefore a simple method may have
123. ed measures based on an estimate of the functionality of the delivered software Function points are the best known of this type of measure Measurement Problems Estimating the size of the measure Estimating the total number of programmer months which have elapsed Estimating contractor productivity e g documentation team and incorporating this estimate in overall estimate Lines of Code e What s a line of code The measure was first proposed when programs were typed on cards with one line per card 112 How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line What programs should be counted as part of the system e Assumes linear relationship between system size and volume of documentation Productivity Comparisons The lower level the language the more productive the programmer The same functionality takes more code to implement in a lower level language than in a high level language The more verbose the programmer the higher the productivity Measures of productivity based on lines of code suggest that programmers who write verbose code are more productive than programmers who write compact code High And Low Level Languages Low level language Analysis Design Coding Validation High level language Analysis Design Coding Validation System Development Times Assembly code High level language 5000
124. eful use of system resources Usability Software must be usable by the users for which it was designed What are the Key Challenges Facing Software Engineering Coping with legacy systems coping with increasing diversity and coping with demands for reduced delivery times Legacy Systems Old valuable systems must be maintained and updated Heterogeneity Systems are distributed and include a mix of hardware and software Delivery There is increasing pressure for faster delivery of software Professional and Ethical Responsibility Software engineering involves wider responsibilities than simply the application of technical skills Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals Ethical behaviour is more than simply upholding the law Issues of Professional Responsibility Confidentiality Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed Competence Engineers should not misrepresent their level of competence They should not knowingly accept work which is out with their competence Intellectual Property Rights Engineers should be aware of local laws governing the use of intellectual property such as patents copyright etc They should be careful to ensure that the intellectual property of employers and clients is protected Computer Misu
125. eir development Software engineering is therefore an engineering discipline where software engineers use methods and theory from computer science and apply this cost effectively to solve difficult problems These difficult problems have meant that many software development projects have not been successful However most modern software provides good service to its users we should not let high profile failures obscure the real successes of software engineers over the past 30 years Software engineering was developed in response to the problems of building large custom software systems for defence government and industrial applications We now develop a much wider range of software from games on specialized consoles through personal PC products and web based systems to very large scale distributed systems Although some techniques that are appropriate for custom systems such as object oriented development are universal new software engineering techniques are evolving for different types of software It is not possible to cover everything in one book so I have concentrated on universal techniques and techniques for developing large scale systems rather than individual software products Although the book is intended as a general introduction to software engineering it is oriented towards system requirements engineering I think this is particularly important for software engineering in the 21st century where the challenge we face is to ensure that our
126. el is unlikely to be appropriate Give reasons why this is the case 131 ONIMAANIDN A AYVMLIOS LESSON 36 LEGACY SYSTEMS Older Software Systems That Remain Vital to an Organisation Objectives To explain what is meant by a legacy system and why these systems are important To introduce common legacy system structures To briefly describe function oriented design To explain how the value of legacy systems can be assessed Topics Covered e Legacy system structures e Legacy system design e Legacy system assessment Legacy Systems Software systems that are developed specially for an organisation have a long lifetime e Many software systems that are still in use were developed many years ago using technologies that are now obsolete e These systems are still business critical that is they are essential for the normal functioning of the business They have been given the name legacy systems Legacy System Replacement e There is a significant business risk in simply scrapping a legacy system and replacing it with a system that has been developed using modern technology e Legacy systems rarely have a complete specification D uring their lifetime they have undergone major changes which may not have been documented Business processes are reliant on the legacy system The system may embed business rules that are not formally documented elsewhere e New software development is risky and may not be
127. el the mail sending and mail receiving processing separately Activity Draw state machine models of the control software for e An automatic washing machine which has different programs for different types of clothes e The software for ac compact disc player e A telephone answering machine on an LED display The system should allow the telephone owner to dial in type a sequence of numbers identified as tones and have the recorded messages replayed over the phone Activity Develop an object model including a class hierarchy diagram and an aggregation diagram showing the principal components of a personal computer system and its system software 41 ONIYSANIDON A AYVMLIOS ONIMAANIDON A AYVMLIOS Activity Develop a sequence diagram showing the interactions involved when a student registers for a course in a university Courses may have a limited number of places so the registration process must include checks that places are available Assume that the student accesses an electronic course catalogue to find out about available courses Activity Describe three modeling activities that may be supported by a CASE workbench for some analysis method Suggest three activities that cannot be automated Notes 42 LESSSON 12 AND 13 SOFTWARE PROTOTY PING Objectives Throw away prototyping to elicit and validate requirements e To describe the use of prototypes in different types of Evolutionary prototyping to
128. em Design e Most legacy systems were designed before object oriented development was used e Rather than being organised as a set of interacting objects these systems have been designed using a function oriented design strategy Several methods and CASE tools are available to support function oriented design and the approach is still used for many business applications A Function oriented View of Design Shared memory Input process output Model Input process output e Input components read and validate data from a terminal or file e Processing components carry out some transformations on that data e Output components format and print the results of the computation Input process and output can all be represented as functions with data flowing between them Functional Design Process e Dataflow design Model the data processing in the system using data flow diagrams Structural decomposition Model how functions are decomposed to sub functions using graphical structure charts that reflect the input process output structure 133 e Detailed design The functions in the design and their interfaces are described in detail These may be recorded in a data dictionary and the design expressed using a PDL Data Flow Diagrams e Show how an input data item is functionally transformed by a system into an output data item e Are an integral part of many design methods and are supported by many CA
129. ement process a process to be followed when analysing the impact and costs of a requirements change e Traceability policies the amount of information about requirements relationships that is maintained e CASE tool support the tool support required to help manage requirements change Traceability e Traceability is concerned with the relationships between requirements their sources and the system design e Source traceability links from requirements to stakeholders who proposed these requirements e Requirements traceability links between dependent requirements Design traceability links from the requirements to the design CASE Tool Support e Requirements storage requirements should be managed in a secure managed data store e Change management the process of change management is a workflow process whose stages can be defined and information flow between the stages partially automated Traceability management automated discovery and documentation of relationships between requirements Requirements Change Management e Should apply to all proposed changes to the requirements e Principal stages Problem analysis discuss identified requirements problem and propose specific change s Change analysis and costing assess effects of change on other requirements Change implementation modify requirements document and others to reflect change Requirements Change Management Key Points
130. en many of these resources will be inaccessible to system users Communications The universal availability of the Internet and the efficient implementation of Internet TCP IP communication protocols means that for most distributed systems these are the most effective way for the computers to communicate However where there are specific requirements for performance reliability etc alternative approaches to communications may be used Quality of service The quality of service offered by a system reflects its performance availability and reliability It is affected by a number of factors such as the allocation of processes to processes in the system the distribution of resources across the system the network and the system hardware and the adaptability of the system Software architectures The software architecture describes how the application functionality is distributed over a number of logical components and how these components are distributed across processors Choosing the right architecture for an application is essential to achieve the desired quality of service Distributed Systems Architectures Client server architectures Ristributed services which are called on by clients Servers that provide services are treated differently from clients that use services Distributed object architectures Removes distinction between clients and servers Any object in the system may provide and use services from oth
131. en successful at increasing system quality Hence the need for formal methods has been reduced Market changes have made time to market rather than quality the key issue for many systems Formal methods do not reduce time to market The scope of formal methods is limited They are not well suited to specifying user interfaces Many interactive applica tions are G UI heavy today Formal methods are hard to scale up to very large systems Although this is rarely necessary The costs of introducing formal methods are high Thus the risks of adopting formal methods on most projects outweigh the benefits However formal specification is an excellent way to find requirements errors and to express requirements unambiguously e Projects which use formal methods invariably report fewer errors in the delivered software e In systems where failure must be avoided the use of formal methods is justified and likely to be cost effective Thus the use of formal methods is increasing in critical system development where safety reliability and security are important Formal Specification in The Software Process Requirements Formal specification X A specification System Architectural modelling design Formal Specification Techniques Sequential Concurrent Algebraic Larch Guttag Horning et Lotos Bolognesi and al 1985 Guttag Brinksm a 1987 Horning et al 1993 OBJ Futatsugi Goguen R
132. entify Principal System Objects e Identifying objects or object classes is the most difficult part OO design e There is no magic formula it relies on the skill experience and domain knowledge of system designers Manages all IN external communications Collects and IN summarises weather data e An iterative process you are unlikely to get it right the first time Approaches to Object Identification e Use a grammatical approach based on a natural language description of the system Abbott s heuristic e Associate objects with tangible things in the application domain e g devices Use a behavioural approach identify objects based on what participates in what behaviour e Use scenario based analysis The objects attributes and methods in each scenario are identified e Use an information hiding based approach Identify potentially change able design decisions and isolate these in separate objects Weather Station Object Classes e Weather station interface of the weather station to its environment It reflects interactions identified in the use case model e Weather data encapsulates summarised data from the instruments Ground thermometer Anemometer Barometer application domain hardware objects related to the instruments in the system Weather Station Object Classes WeatherData airTem peratures groundTemperatures windSpeeds windDirectio
133. entralized systems What are the likely limits on the scalability of the system system model that you have chosen Activity Activity Distributed systems based on a client server model have been What is the fundamental difference between a fat client and a developed since the 1980s but it is only recently that system thin client approach to client server systems development architectures based on disrupted objects have been imple Explain why the use of Java as an implementation language mented Suggest three reasons why this should be the case blurs the distinction between these approaches 65 ONIYMSANIDONA AYVMLIOS ONIMSAANIDON A JAVMI OS Activity Explain why the use of distributed objects with an object request broker simplifies the implementation of scalable client server systems Illustrate your answer with an example Activity How is the CORBA IDL used to support communications between objects that have been implemented in different programming languages Explain why this approach may cause performance problems if there are radical differences between the languages used for object implementation Activity What are the basic facilities that must be provided by an object request broker 66 LESSON 19 AND 20 OBJ ECT ORIENTED DESIGN Objectives To explain how a software design may be represented as a set of interacting objects that encapsulate their own state and operations To describe the activities
134. ents of requirements e Particularly useful in dealing with fragmentary incomplete or conflicting requirements Scenario Descriptions e System state at the beginning of the scenario e Sequence of events for a specific case of some generic task the system is required to accomplish e Any relevant concurrent activities e System state at the completion of the scenario A Simple Scenario e t0 The user enters values for input array A The values are 1 23 4 7 19 The value of output variable BIG remains undefined e t1 The user executes program MAX e t2 The value of variable BIG is 23 and the values of A are 1 23 4 7 19 Scenario Based Requirements Engineering SBRE e Marcel support environment allows rapid construction of an operational specification of the desired system and its environment e Based on a forward chaining rule based language e An interpreter executes the specification to produce natural language based scenarios of system behavior Rule Name Agent SAILORENGHGES_EMEAGENCY_SwiTCR sAiLoR Camel Descriptian The seilar engages the emergency switch Aule Preceaditian OMEN CHOOSES_TO_FLIP_SWWITCH IF SAILOR_AT_BUGY Rule Body SIGNAL SOS_SWITCHFLIPPES TO BUDY SBRE Scenario Generation TE bc o trom ine GLOB Perizeciine amen Will be triggered Scenario Representation in VORD e VORD supports the graphical description of multi threaded
135. equirements High level definition design et al 1985 Model based Z Spivey 1992 CSP Hoare 1985 YDM Jones 1960 Petri Nets Peterson B ordsworth 1996 1981 Algebraic approach the system is specified in terms of its operations and their relationships via axioms Model based approach including simple pre and post conditions the system is specified in terms of a state model and operations are defined in terms of changes to system state Formal Specification Languages Larch Guttag Horning et Lotos Bolognesi and al 1985 Guttag Horning Brinksm a 1987 Algebraic et al 1993 OBJ Futatsugi Goguen et al 1985 Z Spivey 1992 YDM Jones 1980 B Wordsworth 1996 Model based CSP Hoare 1985 Petri Nets Peterson 1981 Use of Formal Specification Formal specification is a rigorous process and requires more effort in the early phases of software development e This reduces requirements errors as ambiguities incompleteness and inconsistencies are discovered and resolved Hence rework due to requirements problems is greatly reduced 49 Development Costs With Formal Specification Cost Validation Design and Implementation Validation Design and Implementation Specification Specification Withoutformal W ith formal specification specification Specification of Sub system Interfaces Large systems are normally comprised of sub sy
136. er objects 61 Middleware e Software that manages and enables communication between the diverse components of a distributed system Middleware is usually off the shelf rather than specially written e Distributed system frameworks e g CORBA and DCOM is an important class of middle ware described later Client server Architectures The application is modelled as a set of services that are provided by servers and a set of clients that use the services e Clients must know of servers but servers need not know of clients e g installing a network printer Clients and servers are logical processes as opposed to physical machines The mapping of processors to processes is not necessarily 1 1 A Client server System Qs sI os Server process Client process Server computer O Client computer Application Layers M odel e Presentation layer concerned with presenting the results of a computation to system users and with collecting user inputs e Application processing layer concerned with implementing the logic functionality of the application Data management layer concerned with all system database operations Application Layers Presentation layer Application processing layer Data management layer Distributing Layers to Processors e Two tier C S archite
137. erent stimuli responses the system architecture must allow for fast switching between stimulus handlers Timing demands of different stimuli are different so a simple sequential loop is not usually adequate Real time systems are usually designed as cooperating processes with a real time executive controlling these processes A Real time System Model Real time control system Actuator Actuator System Elements e Sensors control processes Collect information from sensors May buffer information collected in response to a sensor stimulus Data processor Carries out processing of collected information and computes the system response e Actuator control Generates control signals for the actuator Sensor Actuator Processes Response Actuator control Stimulus Sensor control System Design Design both the hardware and the software associated with system Partition functions to either hardware or software Data processor e Design decisions should be made on the basis on non functional system requirements 74 e Hardware delivers better performance but potentially longer development and less scope for change Hardware and Software Design Establishsystem requirements Partition requirements Software Hardw are requirements requirements Software Hardw are design design R t Systems Design Process e Identify the stimuli to be processed and the required responses t
138. erent super classes have different semantics e Makes class hierarchy reorganisation more complex Voice recording Speaker Duration Recording date Author Edition Publication date ISBN Talking book Object Aggregation Aggregation model shows how classes which are collections are composed of other classes e Similar to the part of relationship in semantic data models 39 Object Behaviour Modelling e A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as ause case Sequence diagrams or collaboration diagrams in the UML are used to model interaction between objects Issue of Electronic Items Ecat Bae Libl Library User Lookup Display Issue licence Accept licence Compress Deliver CASE Workbenches e A coherent set of tools that is designed to support related software process activities such as analysis design or testing e Analysis and design workbenches support system modelling during both requirements engineering and system design These workbenches may support a specific design method or may provide support for a creating several different types of system model An Analysis and Design Workbench Report generation facilities Query language facilities Import export facilities Analysis Workbench Components Diagram editors e Model analysis and checking tools e Repository and associa
139. erfaces should be defined precisely e Object oriented design simplifies system evolution Activity Explain why adopting an approach to design that is based on loosely coupled objects that hide information about their representation should lead to a design which may be readily modified 71 ONIMAANIDON A AYVMLIOS Activity Using examples explain the difference between an object and an object class Activity Under what circumstances might it be appropriate to develop a design where objects execute concurrently Activity Using the UML graphical notation for object classes design the following object classes identifying attributes and operations Use your own experience to decide on the attributes and operations that should be associated with these objects e A telephone e A printer for a personal computer e A personal stereo system e A bank account e A library catalogue Activity Develop the design of the weather station to show the interaction between the data collection sub system and the instruments that collect weather data Use sequence charts to show this interaction 72 Activity Identify possible objects in the following systems and develop an object oriented design for them You may make any reasonable assumptions about the systems when deriving the Activity design Draw a sequence diagram showing the interactions of objects in e A group diary and time management system is intended to a group dia
140. es for component identification Version numbering Attribute based identification Change oriented identification Version Numbering e Simple naming scheme uses a linear derivation eg V1 V1 1 V1 2 V2 1 V2 2 etc e Actual derivation structure is a tree or a network rather than a sequence e Names are not meaningful e Hierarchical naming scheme may be better Version Derivation Structure Attribute based Identification e Attributes can be associated with a version with the combination of attributes identifying that version e Examples of attributes are Date Creator Programming Language Customer and Status etc e More flexible than an explicit naming scheme for version retrieval Can cause problems with uniqueness e Needs an associated name for easy reference Attribute based Queries e An important advantage of attribute based identification is that it can support queries so that you can find the most recent version in Java etc Example AC3D language Java platform NT4 date Jan 1999 Change oriented Identification e Integrates versions and the changes made to create these versions Used for systems rather than components Each proposed change has a change set that describes changes made to implement that change e Change sets are applied in sequence so that in principle a version of the system that incorporates an arbitrary set of changes may be created 151 Release Management e Re
141. es of Prototypes feasibility and usefulness e Principal use is to help customers and developers better e Basis for writing a system specification understand system requirements Prototyping Process Experimentation stimulates anticipation of how a system could be used Establish p ro to ty pe objectives Pro to ty ping E plan _ Define prototype functionality Develop p to to ty pe Executable p ro to ty pe Evaluate p ro to ty pe Evaluation Attempting to use functions together to accomplish some task can easily reveal requirements problems e Other potential uses Evaluating proposed solutions for feasibility E x perimental Prototyping Outcomes Prototyping Back to back system testing e Improved system usability Closer match to the system needed Training users before system delivery e Improved design quality maybe e Prototyping is most often undertaken as a risk reduction e Improved maintainability maybe tivity E k Reduced overall development effort maybe but corrective Classifying Prototypes maintenance costs are usually reduced e By purpose 43 Prototyping in The Software Process Evolutionary prototyping prototype is produced and refined through a number of stages to become the final system Throwaway prototyping prototype is produced to help elucidate validate requirements and then discarded The system is then deve
142. ess e Methodical Processes supported by some development method such as HOOD e Supported Processes supported by automated CASE tools Process Applicability Informal process Prototy pes Short lifetime products 4GL business systems Lar ge systems Long lifetime products Well un ders to od application domains Managed process Methodical process Re engineered systems Process Choice e Process used should depend on type of product which is being developed For large systems management are usually the principal problem so you need a strictly managed process For smaller systems more informality is possible e There is no uniformly applicable process which should be standardised within an organisation High costs may be incurred if you force an inappropriate process on a development team Process Tool Support Giri Configuration tools management tools Project Analysis and Specialized managerent design tools tools workbenches Key Points e Process improvement involves process analysis standardisation measurement and change e Process models include descriptions of tasks activities roles exceptions communications deliverables and other processes e Measurement should be used to answer specific questions about the software process used e The three types of process metrics which can be collected are time metrics resource utilisation metrics and event metrics
143. essage Room number Alarm Alarm Alarm system oS 9S ter yy ooo Systeme y y Audible alarm Lighting control Voice synthesizer process process process Building Monitor Process 1 See http www software engin com for links to the complete Java code for this example class BuildingMonitor extends Thread BuildingSensor win door move Siren siren new Siren Lights lights new Lights Synthesizer synthesizer new Synthesizer DoorSensors doors new DoorSensors 30 WindowSensors windows new WindowSensors 50 MovementSensors movements new MovementSensors 200 PowerMonitor pm new PowerMonitor BuildingMonitor initialise all the sensors and start the processes siren start lights start synthesizer start windows start doors start movements start pm start Building Monitor Process 2 public void run int room 0 while true poll the movement sensors at least twice per second 400 Hz move movements getVal poll the window sensors at least twice second 100 Hz win windows getVal poll the door sensors at least twice per second 60 Hz door doors getVal if move sensorVal 1 door sensorVal 1 win sensorVal 1 a sensor has indicated an intruder if move sensorVal 1 room move room if door sensorVal 1 room door room if win sensorVal 1 room win room
144. exception i s a description of ho w to modify the process if some anticipated or unanticipated event occurs Exceptions are often undefined and it is left to the ingenuity of th e project managers and engineers to handle the exception Communi cation represented by an arrow An interchange of information bet ween people or between people and supporting computer systems Communi cation s may be informal or formal Formal communications migh t be the approv al of a deliverable by a project manager informal communications might be the interchange of electronic mail toresolve ambiguiti es in a document The Module Testing Activity Role Post condition All defined tests run onmodule Module compiles without syntax errors Signed off test Activities in M odule Testing TEST DATA PREPAR ATION Prepare test data Read module p Submit test data according to Review testdaa specification 8 for review specification MODULE TEST HARNESS PREPARATION Read and understand Prepare test harness Compile test module interface for module harness Check out module from configuration management system TEST EXECUTION Incorporate module Run approved tests Record test results with test harness onmodule for regression tests TEST REPORTING Write report on module testing including details of discovered problems Submit report Submittest for approval results to CM Process Exception
145. experience is particularly important in software development External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality e Care must be taken not to impose inappropriate process standards Process based Quality Define process Assess produc quality Improve Standardize plocess process Practical Process Quality Define process standards such as how reviews should be conducted configuration management etc e Monitor the development process to ensure that standards are being followed Report on the process to project management and software procurer Quality Planning e A quality plan sets out the desired product qualities and how these are assessed and define the most significant quality attributes e It should define the quality assessment process e It should set out which organisational standards should be applied and if necessary define new standards Quality Plan Structure Product introduction e Product plans e Process descriptions e Quality goals e Risks and risk management e Quality plans should be short succinct documents If they are too long no one will read them Software Quality Attributes Safety Understandability Portability Security Testability Usability Reliability Adaptability Reusability Resilience Modularity Efficiency Robustness Complexity Learnability Quality Control Che
146. f prototyping in the software development process in your organization Write a report for your manager discussing the classes of project where prototyping should be used and setting out the expected costs and benefits form using prototyping Activity Explain why for large systems development it is recommended that prototypes should be throw away prototypes 46 Activity Under what circumstances would you recommend that prototyping should be used as a means of validating system requirements Activity Suggest difficulties that might arise when prototyping real time embedded computer systems Activity Discuss prototyping using reusable components and suggest problems which may arise using this approach What is the most effective way to specify reusable components Activity You have been asked by a charity to prototype a system that keeps track of tall donations they have received This system has to maintain the names and addresses of donors their particular interests the amount donated and when it was donation e g it must be spent on a particular project and the system must keep track of these donations and how they were spent D iscuss how you would prototype this system bearing in mind that the charity has a mixture of paid workers and volunteers Many of the volunteers are retirees who have had little or no computer experience 47 ONIMSANIDNA AYVMLAIOS ONIMAANIDN A AYVMLIOS Activity You have developed
147. f the software is underestimated Risk Analysis Assess probability and seriousness of each risk Probability may be very low low moderate high or very high Risk effects might be catastrophic serious tolerable or insignificant Risk Probability Effects Organisational financial problems force reductions Low Catastrophic in the project budget It is impossible to recruit staff with the skills High Catastrophic required for the project Key staff are ill_at critical times in the project Moderate Serious Software components which should be reused Moderate Serious contain defects which limit their functionality Changes to requirements which require major Moderate Serious design rework are proposed The organisation is restructured so that different High Serious management are responsible for the project The database used in the system cannot process Moderate Serious as many transactions per second as expected The time required to develop the software is High Serious underestimated CASE tools cannot be integrated High Tolerable Customers fail to understand the impact of Moderate Tolerable requirements changes Required training for staff is not available Moderate Tolerable The rate of defect repair is underestimated Moderate Tolerable The size of the software is underestimated High Tolerable The code generated by CASE tools is inefficient Moderate Insignificant Risk Planni
148. f the system operates according to its specification The Defect Testing Process 5 data Prepare test Rinprogram Conpareresults data withtest dta totes cases Black box Testing e An approach to testing where the program is considered as a black box e The program test cases are based on the system specification Test planning can begin early in the software process Inputs causing anomalous behaviour Outputs which reveal the presence of defects Output test results Equivalence Partitioning Input data and output results often fall into different classes where all members of a class are related e Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member Test cases should be chosen from each partition 97 lt 5 Valid inputs Invalid inputs Outputs e Partition system inputs and outputs into equivalence sets If input is a 5 digit integer between 10 000 and 99 999 equivalence partitions are lt 10 000 10 000 99 999 and gt 10 000 Choose test cases at the boundary of these sets 00000 09999 10000 99999 10001 Equivalence Partitions Between 4and 10 More than 10 Number of input values 9999 100000 th m WH Less than 10000 Between 10000and 99999 More than 99999 Input values Search Routine Specification Procedure Search Key ELEM T ELEM_ARRAY Found in out BOOLEAN L in out ELEM IND
149. fication of the requirement Source Who raised this requirement Customer Satisfaction some dependency on this one Supporting Materials History Creation changes deletions ete requirement Requirement Type Customer Dissatisfaction 4 Dependencies Alist of other requirements that have Gorflicts Pointer to documents that ilustrate and explain this e Examples include Ross Structured Analysis SA Volere Requirements Process www volere co uk Knowledge Acquisition and Sharing for Requirement Engineer ing KARE wwwkare org Somerville s Viewpoint Oriented Requirements D efinition VORD and The baut s Scenario Based Requirements E nginering SBRE and Esoluction n r a a_i vive ments Pe ee Pissing Requin te S Eede wed Speadieation copie Stakeholders 5 hiara germat Fisks and Casts n St mtegic Plan far Podu list of events requrement Eventfuse case fh intention of the requirement Fit Criterion A measurement of the requirement such that it is possible to test if the solution matches the original requirement Other require that cannot implemented ifi this meis Volere Copyry rhe Atlante Syetena Grid Degree of stakeholder happiness if this reguirement is successfully implemented Seale from 1 uninterested to F extremely pleased Measure of stakeholder unhappiness if this requirement is not part of the final product Seale from
150. find it difficult to introduce program inspec tions as a V amp V technique 95 ONIYSANIDON A AYVMLIOS ONIMSAANIDNA AYVMLIOS Activity Using your knowledge of Java C C or some other pro gramming language derive a checklist of common errors not syntax errors which could not be detected by a complier but which might be detected in a program inspection Activity Read the published papers on clean room development and write a management report highlighting the advantages costs and risks of adopting this approach to software development Activity A manager decides to use the reports of program inspections as an input to the stag appraisal process These reports show who made and who discovered program errors Is this ethical managerial behaviour Would it be ethical if the staff were informed in advance that this would happen What difference might it make to the inspection process Activity One approach which is commonly adapted to system testing is to test the system until the testing budget is exhausted and then deliver the system to customers Discuss the ethics of this approach 96 LESSON 27 AND 28 SOFTWARE TESTING Objectives To understand testing techniques that are geared to discover program faults To introduce guidelines for interface testing To understand specific approaches to object oriented testing To understand the principles of CASE tool support for testing Topics Covered
151. for specific systems Requirements Document Structure e Preface readers version change history e Introduction e Glossary e User requirements definition e System requirements specification e System models e System evolution e Appendices e Index Key Points e Requirements set out what the system should do and define constraints on its operation and implementation e Functional requirements set out services the system should provide e Non functional requirements constrain the system being developed or the development process e User requirements are high level statements of what the system should do e User requirements should be written in natural language tables and diagrams e System requirements are intended to communicate the functions that the system should provide e System requirements may be written in structured natural language a PDL or in a formal language e A software requirements document SRS is the agreed statement of system requirements Activity Discuss the problems of using natural language for defining user and system requirements and show using small examples how structuring natural language into forms can help avoid some of these difficulties Activity Discuss ambiguities or omissions in the following statements of requirements for part of a ticket issuing system An automated ticket issuing system sells rail tickets Users select their destination and input a credit card and a perso
152. from different places Some indication of where the user is positioned in the help system is valuable Facilities should be provided to allow the user to navigate and traverse the help system Entry Points to a Help System Top level entry Entry from application Entry from error message system Help frame network Help System Windows Help frame map Mail may be redirected to another network user by pressing the redirect button in the control panel The system asks for the name of the user or users to whom the mail has been sent You are here 1 Mail 2 Send mail 3 Read mail 4 Redirection User Documentation e As well as on line information paper documentation should be supplied with a system Documentation should be designed for a range of users from inexperienced to experienced e As well as manuals other easy to use documentation such as a quick reference card may be provided User Document Types System System Tnstdlation Experienced System users administrators Functional description Description of services Administrator s guide Operation and maintenance Document Types e Functional description Brief description of what the system can do e Introductory manual Presents an informal introduction to the system e System reference manual Describes all system facilities in detail e System installation manual Describes how to install the
153. g N dose cumulative_dose 10 r1 12 N used to record the last 3 readings taken capacity N alarm off on pump dis playl display2 STRING dose capacity dose 5 cumulative_dose 50 capacity 40 gt display1 capacity 39 capacity 10 gt display1 Insulin low capacity 9 gt alarm on display1 Insulin very low 12 reading every 10 minutes The Dosage Computation e The insulin pump computes the amount of insulin required by comparing the current reading with two previous readings e If these suggest that blood glucose is rising then insulin is delivered Information about the total dose delivered is maintained to allow the safety check invariant to be applied Note that this invariant always applies there is no need to repeat it in the dosage computation DOSAGE Schema DOS AGE operations change state Alstlin_ Pump dase u imports state amp predicates 11 10 4 12 11 V 11 gt 10 4 12 lt rl V r1 lt 10 r1 12 gt r0 11 dose 4 A T1 210 2 r1 V rl lt 10 E1 r2 10 r1 dose r2 r1 4 A r1 210 4 2 gt r1 V r1 gt 10 2 r1 r1 10 2 j Cupacty capnciysdose X value of x after operation cumulative_dose cumulative_dose dose r rl A rl r2 Output Schemas The output schemas model the system displays and the alarm that indicates some potentially d
154. g to be accepted as part of a group Human Needs Hierarchy Self realization needs Motivating People e Motivations depend on satisfying needs e It can be assumed that physiological and safety needs are satisfied 105 e Social esteem and self realization needs are most significant from a managerial viewpoint Need Satisfaction e Social Provide communal facilities Allow informal communications e Esteem Recognition of achievements Appropriate rewards e Self realization Training people want to learn more Responsibility Personality Types e The needs hierarchy is almost certainly an over simplification e Motivation should also take into account different personality types Task oriented Self oriented Interaction oriented e Task oriented The motivation for doing the work is the work itself e Self oriented The work is a means to an end which is the achievement of individual goals e g to get rich to play tennis to travel etc e Interaction oriented The principal motivation is the presence and actions of co workers People go to work because they like to go to work Motivation Balance e Individual motivations are made up of elements of each class e Balance can change depending on personal circumstances and external events However people are not just motivated by personal factors but also by being part of a group and culture People go to work because they are motivated by
155. g As Individuals And In Groups Objectives To describe simple models of human cognition and their relevance for software managers e To explain the key issues that determine the success or otherwise of team working To discuss the problems of selecting and retaining technical staff To introduce the people capability maturity model P CMM Topics Covered e Limits to thinking e Group working Choosing and keeping people e The people capability maturity model People in the Process e People are an organisation s most important assets e The tasks of a manager are essentially people oriented Unless there is some understanding of people management will be unsuccessful Software engineering is primarily a cognitive activity Cognitive limitations effectively limit the software process Management Activities Problem solving using available people Motivating people who work on a project e Planning what people are going to do e Estimating how fast people will work e Controlling people s activities Organising the way in which people work Limits to Thinking People don t all think the same way but everyone is subject to some basic constraints on their thinking due to Memory organisation Knowledge representation Motivation influences e If we understand these constraints we can understand how they affect people participating in the software process Memory Organisation From
156. ge analyser G Dean Analysis date 10 12 98 Components affected Display Icon Select Display Icon Display Associated components FileTable Change assessment Relatively simple to implement as a file name table is available Requires the design and implementation of a display field No changes to associated components are required Change priority Low Change implementation Estimated effort 0 5 days Date to CCB 15 12 98 CCB decision date 1 2 99 CCB decision Accept change Change to be implemented in Release 2 1 Change implementor Date of change Date submitted to QA QA decision Date submitted to CM Comments Change Tracking Tools e A major problem in change management is tracking change status 150 e Change tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time e Integrated with E mail systems allowing electronic change request distribution Change Control Board Changes should be reviewed by an external group who decide whether or not they are cost effective from a strategic and organizational viewpoint rather than a technical viewpoint Should be independent of project responsible for system The group is sometimes called a change control board May include representatives from client and contractor staff Derivation History Record of changes applied to a document or code component e Shoul
157. ge management faults is no longer Exception management faults Approximate Inspection Rate e 500 statements hour during overview e 125 source statement hour during individual preparation 90 125 statements hour during inspection meeting e Inspection is therefore an expensive process e Inspecting 500 lines costs about 40 person hours assuming 4 participants Cleanroom Software Development The name is derived from the Cleanroom process in semiconductor fabrication The Philosophy is Defect Avoidance Rather Than Defect Removal e A software development process based on Incremental development if appropriate Formal specification Static verification using correctness arguments Statistical testing to certify program reliability NO defect testing The Cleanroom Process Formally Error rework specify system y Define Construct Formally structured verify program code software increments Design statistical tests Integrate increment Develop operational profile Test integrated system 94 Cleanroom Process Teams e Specification team responsible for developing and maintaining the system specification e Development team responsible for developing and verifying the software The software is NOT executed or even compiled during this process e Certification team responsible for developing a set of statistical tests to m
158. ge scale applications with hundreds or thousands of clients multi tier C S Applications where both the data and the application are architecture volatile Applications where data from multiple sources are integrated Distributed Object Architectures e Eliminates the distinction between clients and servers e System components are objects that provide services to and receive services from other objects Object communication is through middle ware called an object request broker effectively a software bus Distributed Object Architectures Advantages of Distributed Object Architectures e Allows system designer to delay decisions on where and how services should be provided Service providing objects may execute on any network node e Very open architecture allows new resources to be added as required e Flexible and scaleable e System is dynamically reconfigurable objects can migrate across the network as required Thus improving performance Uses of Distributed Object Architectures e Asa logical model for structuring and organizing a system solely in terms of services provided by a number of distributed objects E g a data mining system e Asa flexible means of implementing C S systems Both clients and servers are realised as distributed objects communicating through a software bus A Data Mining System Database 1 Disadvantages of Distributed Object Architectures e Complex to design due t
159. gh costs associated with this support it may be worth considering system replacement Maintenance What are the costs of hardware maintenance and support software costs licences Older hardware may have higher maintenance costs than modern systems Support software may have high annual licensing costs Interoperability Are there problems interfacing the system to other systems Can compilers etc be used with current versions of the operating system Is hardware emulation required Application Assessment Factor Questions Undestandbility How dfficult is it to undestand thesource code df the current system Howcompkx are the contol structures which are used Do variables have meaningul mmes tha reflect their function Docunentation Wht system deumertation k availabk Is the deumertation complete corsistent and upto date Data Is there an explicit dat modd for the system Towhat extent is data duplicated in dfferentfiles Is the data used by thesystem up to date and consstent Performance Is the performance of the application adequte Do performance problems havea signficant fect onsystem users Programming Are mom complers available for the programming hnguage wed to language develop tle system Is the programming language still used for new system cevelopment Configuration Axe all versions of all parts of the system managed bya configuration management managanentsystem Is there an explicit description
160. gible nature of software causes problems for management e Managers have diverse roles but their most significant activities are planning estimating and scheduling e Planning and estimating are iterative processes which continue throughout the course of a project e A project milestone is a predictable state where some formal report of progress is presented to management e Risks may be project risks product risks or business risks e Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats Activitiy Explain why the intangibility of software systems poses special problems for software project management Activitiy Explain why the best programmers do not always make the best software managers 17 ONIYSANIDON A AYVMLIOS ONIMSANIDONA AYVMLIOS Activity Explain why the process of project planning is an iterative one and why a plan must be continually reviewed during a software project Activity Briefly explain the purpose of each of the sections in a software project plan Activity What is the critical distinction between a milestone and a deliverable Activity Following figure sets out a number of activities durations and dependencies D raw an activity chart and a bar chart showing the project schedule 18 Activity Notes You are asked by your manager to deliver software to a sched ule
161. gnificant for short duration projects where there is insufficient time to learn a new language May provide an indicator of the basic fundamentals which the candidate should know and of their ability to learn This factor becomes increasingly irrelevant as engineers gain experience across a range of rojects Very important because of the need forproject staff to communicate orally and in writing with other engineers managers and customers Adaptability may be judged by looking at the different types of experience which candidates have hadThis is an important attribute as it indicates an ability to learn Project staff should have a positive attitude to their work and should be willing to learn new skills This is an important attribute but often very difficult to assess Again an important attribute but difficult to assess Candidates must be reasonably compatible with other team members No particular type of personality is more or less suited to software engineering Programming language experience Educational background Communication ability Adaptability Attitude Personality Working Environments e Physical workplace provision has an important effect on individual productivity and satisfaction Comfort Privacy Facilities Health and safety considerations must be taken into account Lighting Heating Furniture Environmental Factors e Privacy each eng
162. he pattern analysis and experience The Observer Pattern Details P 323 e Name Observer Description Separates the display of object state from the object itself e Problem description Used when multiple displays of state are needed Solution description See UML description e Consequences Optimisations to enhance display performance are impractical Multiple Displays 82 The Observer Pattern Observer Attach Observer De rs ORT for all o in observek gt o gt Update ConcreteSubject E EAA ANS Get State return subjectState subjectState ConcreteO bserver Update obsaverState D subject gt GetState observerState Key Points Design with reuse involves designing software around existing examples of good design and making use of existing software elements e Advantages are lower costs faster software development and lower risks e CBSE relies on black box components with defined requires and provides interfaces e Software components for reuse should be independent reflect stable domain abstractions and provide access to state through interface operations e COTS product reuse is concerned with the reuse of large scale off the shelf systems e Application families are related applications that have a common domain specific architecture e Design patterns are high level abstractions that document successful de
163. ics help assess complexity understandability and maintain ability Dynamic and Static Metrics e Dynamic metrics are closely related to software quality attributes It is relatively easy to measure the response time of a system performance attribute or the number of failures reliability attribute Static metrics have an indirect relationship with quality attributes You need to try and derive a relationship between these metrics and properties such as complexity understandability and maintainability Softw are Product Metrics Software metric Description Fan in Fan out Fan in is a measure of the number of functions that call some other function say X Fan out is the number of functions which are called by function X A high value for fan in means that X is tightly coupled to the rest of the design and changes to X will have extensive knock on effects A high value for fan out suggests that the overall complexity of X may be high because of the complexity of the control logic needed to coordinate the called components Length of code This is a measure of the size of a program Generally the larger the size of the code of a program s components the more complex and error prone that component is likely to be Cyclomatic This is a measure of the control complexity of a program This complexity control complexity may be related to program understandability The computation of cyclomatic complexity is cover
164. igh level system design e A sub system is usually a system in its own right and is sometimes called a Product e A module is a lower level element that would not normally be considered a separate system modules are sometimes called Components or Objects Traditional and Somerville s terminology System System Product Sub System Component Module Module Unit Algorithm Architectural Models e Different types of models may be used to represent an architectural design e Each presents a different perspective on the architecture Architectural Model Types e Static structural models show the major system components e Dynamic process models show the process structure of the system at run time e Interface models define the sub system services offered through public interfaces Relationship models show relationships such as a dataflow among sub systems Architectural Styles The architecture of a system may conform to a single generic model or style although most do not e An awareness of these styles and how they can affect system attributes can simplify the problem of choosing an appropriate architecture System Attributes And Architectural Styles Structures e Performance localize operations by using fewer large grain components to minimize sub system communication e Security use a layered architecture with critical assets in inner layers e Safety isolate safety critical components i
165. in a management routine Call return Model Manager Model Real time System Control Q Computation processes K Sensor Actuator processes processes System controller User interface Fault handler Principal Event based Control Models 1 2 Broadcast model an event is broadcast to all sub systems any sub system which can handle the event may do so Interrupt driven model used in real time systems where interrupts are detected by an interrupt handler and passed to some other component for processing Other event based models include compound documents and production systems Broadcast M odel Effective in integrating sub systems executing on different computers in a network Control policy is NOT embedded in the message handler sub systems register an interest in specific events and the event handler ensures that these events are sent to them Registration of interests supports selective broadcasting Evolution is relatively easy since a new sub system can be integrated by registering its events with the event handler However sub systems don t know if or when an event will be handled by some other sub system Interrupt driven Systems Used in real time systems where fast response to an event is essential A handler is defined for each type of interrupt Each type is associated with a memory location and a hardware switch causes transfer to its handler fast 56 e Allo
166. in each server No central register of names and services so it may be hard to find out what servers and services are available The Abstract M achine M odel Organizes a system into a series of layers Each layer defines an abstract machine and provides a set of services used to implement the next level of abstract machine When a layer interface changes only the adjacent layer is affected However it is often difficult to structure systems in this way Why Abstract Machine Based Version Management System Version management Object management Database system Operatin g system Control M odels Concerned with the control flow between sub systems Distinct from the system structure model Two general approaches Centralized control one sub system has overall responsibility for control and starts and stops other sub systems Event based control each sub system can respond to externally generated events from other sub systems or from the system s environment Centralized Control Models 1 N Call return model top down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards Applicable to sequential systems only Manager model applicable to concurrent systems One system component controls the stopping starting and coordination of other system processes Also applicable to sequential systems where it is usually implemented as a case statement with
167. ineer requires an area for uninterrupted work e Outside awareness people prefer to work in natural light e Personalization individuals adopt different working practices and like to organize their environment in different ways Workspace Organisation e Workspaces should provide private spaces where people can work without interruption Providing individual offices for staff has been shown to increase productivity However teams working together also require spaces where formal and informal meetings can be held Office Layout Communal area Shared documentation The People Capability Maturity Model e Intended as a framework for managing the development of people involved in software development e Five stage model Initial Ad hoc people management Repeatable Policies developed for capability improvement Defined Standardised people management across the organisation Managed Quantitative goals for people management in place Optimising Continuous focus on improving individual competence and workforce motivation The People Capability Maturity M odel Optimizing Continuous workforce innovation Coaching nt Continuously improve methods for develo ping personal and organisational competence Personal Competency Developme Managed Organisational Performance Alignment Organisational Competency Management Team based Practices Team Building Mentoring Quantitatively manage organisat
168. ing e CASE tools for configuration management Configuration Management New versions of software systems are created as they change For different machines OS Offering different functionality Tailored for particular user requirements e Configuration management is concerned with managing evolving software systems System change is a team activity CM aims to control the costs and effort involved in making changes to a system e Involves the development and application of procedures and standards to manage an evolving software product e May be seen as part of a more general quality management process e When released to CM software systems are sometimes called baselines as they are a starting point for further development Mainframe version Works tation version System Families PC version DEC version Sun version VMS version Unix version Initial system CM Standards CM should always be based on a set of standards which are applied within an organisation e Standards should define how items are identified how changes are controlled and how new versions are managed e Standards may be based on external CM standards e g IEEE standard for CM e Existing standards are based on a waterfall process model new standards are needed for evolutionary development Concurrent Development And Testing e A time for delivery of system components is agreed e A new version of a system
169. initial implementation e Maintenance to add to or modify the system s functionality Modifying the system to satisfy new requirements Distribution of Maintenance Effort Fault repair 17 Functionality addition or modification 65 Software adaptation 18 Spiral Maintenance Model Seiten _ ionene Release 1 J Release 2 Release 3 Maintenance Costs Usually greater than development costs 2 to 100 depending on the application e Affected by both technical and non technical factors e Increases as software is maintained Maintenance corrupts the software structure so makes further maintenance more difficult Ageing software can have high support costs e g old languages compilers etc Development Maintenance Costs System 1 System 2 0 50 100 150 200 250 300 350 400 450 soo Ej Development costs L Maintenance costs Maintenance Cost Factors Team stability Maintenance costs are reduced if the same staff are involved with them for some time e Contractual responsibility The developers of a system may have no contractual responsi bility for maintenance so there is no incentive to design for future change e Staff skills Maintenance staff are often inexperienced and have limited domain knowledge e Program age and structure As programs age their structure is degraded and they become harder to understand and change Evolutiona
170. ion Often easier with bottom up integration testing Test observation Problems with both approaches Extra code may be required to observe tests Interface Testing Takes place when modules or sub systems are integrated to create larger systems e Objectives are to detect faults due to interface errors or invalid assumptions about interfaces Particularly important for object oriented development as objects are defined by their interfaces 100 Interfaces Types e Parameter interfaces Data passed from one procedure to another e Shared memory interfaces Block of memory is shared between procedures Procedural interfaces Sub system encapsulates a set of procedures to be called by other sub systems e Message passing interfaces Sub systems request services from other sub systems Interface Errors e Interface misuse A calling component calls another component and makes an error in its use of its interface e g parameters in the wrong order e Interface misunderstanding A calling component embeds assumptions about the behaviour of the called component which are incorrect e Timing errors The called and the calling component operate at different speeds and out of date information is accessed Interface Testing Guidelines e Design tests so that parameters to a called procedure are at the extreme ends of their ranges e Always test pointer parameters with null pointers Design tests which cause the
171. ional gro wth in workforce cap abilities and establish competency based teams care Defined Identify primary competencies and align workforce activities with them Participatory Culture Competency based Practices Career Develop ment Competency Development Workforce Planning Knowledge and Skills Analy sis Repeatable Instill basic discipline into workforce activities Compensation Trainin g Performance Management Staffing Communication Work environment Initial P CMM Objectives To improve organisational capability by improving workforce capability To ensure that software development capability is not reliant on a small number of individuals e To align the motivation of individuals with that of the organisation To help retain people with critical knowledge and skills 108 Key Points e Managers must have some understanding of human factors to avoid making unrealistic demands on people e Problem solving involves integrating information from long term memory with new information from short term memory e Staff selection factors include education domain experience adaptability and personality Software development groups should be small and cohesive e Group communications are affected by status group size group organisation and the sexual composition of the group The working environment has a significant effect on productivity e The People Capability Maturity Mo
172. is built from these components by compiling and linking them e This new version is delivered for testing using pre defined tests Faults that are discovered during testing are documented and returned to the system developers Daily System Building e It is easier to find problems that stem from component interactions early in the process e This encourages thorough unit testing Developers are under pressure not to break the build e A stringent change management process is required to keep track of problems that have been discovered and repaired Configuration Management Planning e All products of the software process may have to be managed Specifications Designs Programs Test data User manuals Thousands of separate documents are generated for a large software system CM Planning e Starts during the early phases of the project e Must define the documents or document classes which are to be managed Formal documents Documents which might be required for future system maintenance should be identified and specified as managed documents The CM Plan e Defines the types of documents to be managed and a document naming scheme Defines who takes responsibility for the CM procedures and creation of baselines Defines policies for change control and version management Defines the CM records which must be maintained 149 e Describes the tools which should be used to assist the CM process and
173. ity Is the process designed in such a way that process errors are avoided or trapped before they result in product errors Robustness Can the process continue in spite of unexpected problems Maintainability Can the process evolve to reflect changing organisational requirements or identified process improvements Rapidity How fast can the process of delivering a system from a given specification be completed Process Improvement Stages e Process analysis Model and analyse quantitatively if possible existing processes Improvement identification Identify quality cost or schedule bottlenecks e Process change introduction Modify the process to remove identified bottlenecks e Process change training Train staff involved in new process proposals e Change tuning Evolve and improve process improvements The Process Improvement Process Introduce process change Process and Product Quality e Process quality and product quality are closely related e A good process is usually required to produce a good product e For manufactured goods process is the principal quality determinant e For design based activity other factors are also involved especially the capabilities of the designers Principal Product Quality Factors Development technology Process Product People quality quality quality Cost time and schedule Quality Factors e For large projects with average capabilities the development process de
174. ject classes that work together e System abstraction an entire self contained system e g MS Excel CBSE Processes e Component based reuse may be opportunistic or it may drive the development process e In reuse driven development system requirements are modified to reflect the available components CBSE often involves an evolutionary development process with components being glued together using a scripting language e g Unix shell Visual Basic TCL TK An Opportunistic Reuse Process Specify components the we might get lucky approach Search for reusable components Incorporate dis covered components Design system aachitecture Reuse driven Development Modify requirements Outline Search for H according to system TOBATE discovered requirements components components Specify system Architectural eae companents design eg based on reusable components components CBSE Problems e Component incompatibilities may mean that cost and schedule savings are less than expected e Finding and understanding components repositories and tool support are lacking e Managing evolution as requirements change source code is typically not available waiting for the next release Application Families e An application family or product line is a related set of applications that has a common domain specific architecture
175. k Monitoring e Assess each identified risk regularly to decide whether or not it is becoming less or more probable e Also assess whether the effects of the risk have changed e Each key risk should be discussed at management progress meetings Risk Factors Risk Strategy Organisational financial problems Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business Recruitment Alert customer of potential difficulties and the possibility of delays investigate problems buying in components Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other s jobs Defective Replace potentially defective components with bought in components of known components reliability Requirements Derive traceability information to assess requirements change impact maximise changes information hiding in the design Organisational restructuring Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business Database performance Investigate the possibility of buying a higher performance database Underestimated development time Investigate buying in components investigate use of a program generator Key Points e Good project management is essential for project success e The intan
176. leases must incorporate changes forced on the system by errors discovered by users and by hardware changes They must also incorporate new system functionality e Release planning is concerned with when to issue a system version as a release System Releases e Not just a set of executable programs e May also include Configuration files defining how the release is configured for a particular installation Data files needed for system operation An installation program or shell script to install the system on target hardware Electronic and paper documentation Packaging and associated publicity e Systems are now normally released on CD ROM or as downloadable installation files from the web Release Problems e Customer may not want a new release of the system They may be happy with their current system as the new version may provide unwanted functionality e Release management must not assume that all previous releases have been accepted All files required for a release should be re created when a new release is installed Release Decision Making Preparing and distributing a system release is an expensive process e Factors such as the technical quality of the system competition marketing requirements and customer change requests should all influence the decision of when to issue a new system release System Release Strategy Factor Description Technical quality of the system If serious system faults are repo
177. led in older legacy systems Legacy System Structures Services L Services User interface Database Ideal model for distribution Real legacy systems Layered Distribution Model Presentation Data validation Interaction control Application services Database 141 Legacy System Distribution Desktop PC clients running application Application services User interface Legacy system Character terminals Distribution Options The more that is distributed from the server to the client the higher the costs of architectural evolution The simplest distribution model is UI distribution where only the user interface is implemented on the server The most complex option is where the server simply provides data management and application services are implemented on the client Distribution Option Spectrum Server Services Database Server Interaction control Data validation Services Database Client Presentation Client Presentation Client Presentation Interaction control Interaction control Data validation Data validation Services J Increasing cost and effort Server Database User Interface Distribution UI distribution takes advantage of the local processing power on PCs to implement a graphical user interface e Where there is a clear separation between the UI and the application then the legacy system can be modified to distribute the UI Otherwise screen m
178. lines 1500 lines 28 weeks 20 weeks 714 lines month Assembly code i 300 lines month High level language Function Points Based on a combination of program characteristics External inputs and outputs User interactions External interfaces Files used by the system e A weight is associated with each of these The function point count is computed by multiplying each raw count by the weight and summing all values Function point count modified by complexity of the project e FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language LOC AVC number of function points AVC is a language dependent factor varying from 200 300 for assemble language to 2 40 fora4GL e FPs are very subjective They depend on the estimator Automatic function point counting is impossible Object Points Object points are an alternative function related measure to function points when 4G ls or similar languages are used for development Object points are NOT the same as object classes e The number of object points in a program is a weighted estimate of The number of separate screens that are displayed The number of reports that are produced by the system The number of 3GL modules that must be developed to supplement the 4G L code Object Point Estimation e Object points are easier to estimate from a specification than function points as they are simply concerned with screens repo
179. loped using some other development process Starting Points e In evolutionary prototyping development starts with those requirements which are best understood e In throwaway prototyping development starts with those requirements which are least understood Approaches to Prototyping Evolutionary prototy ping Throw away Prototy ping Evolutionary Prototyping Often used when a specification cannot be developed in advance e g AI systems and GUI applications Delivered system Executable Prototype System Specification Outline Requirements e System is developed as a series of prototype versions delivered to the customer for assessment Verification is unnecessary as there is no specification Validation involves assessing the adequacy of the system Use prototype system System adequate Techniques for rapid system development are used such as CASE tools and 4GLs e User interfaces are usually developed using a G UI development toolkit Advantages of Evolutionary Prototyping Over Normal System Development e Accelerated delivery Quick availability is sometimes more important than details of functionality or maintainability e User engagement System is more likely to meet user requirements and users are more likely to want to make it work Evolutionary Prototyping Problems e Management problems Poor fit with existing waterfall management model Specialized devel
180. ls Complete nouication onder orm Data Flow Diagrams DFDs model the system from a functional perspective e Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment CASE Toolset DFD Input Valid Checked Design User design design design analysis report Design Design Design Report editor cross checker analy ser generator Referenced Checked desig ns design Output code Design datab ase State Machine Models e These model the behaviour of the system in response to external and internal events Code skeleton Design generator database e They show the system s responses to stimuli so are often used for modelling real time systems e State machine models show system states as nodes and events as arcs between these nodes When an event occurs the system moves from one state to another e State charts are an integral part of the UML Microw ave Oven Model Full power Full power do set power 600 Timer Waitin do display Number time number Settime Half Pa i Door P Timer closed Cancel Door open Half power Door do display do set power 300 Ready do display Waiting Microwave Oven State Description
181. lt get CircularBuffer Key Points e Real time system correctness depends not just on what the system does but also on how fast it reacts e A general RT system model involves associating processes with sensors and actuators e Real time systems architectures are usually designed as a number of concurrent processes Real time executives are responsible for process and resource management Monitoring and control systems poll sensors and send control signal to actuators Data acquisition systems are usually organised according to a producer consumer model 78 e Java has facilities for supporting concurrency but is not suitable for the development of time critical systems Activity Using examples explain why real time systems usually have to be implemented using processes Activity Explain why an object oriented approach to software develop ment may not be suitable for real time systems Activity Draw state machine models of the control software for the following systems e An automatic washing machine which has different programs for different types of clothes e The software for a compact disc player e A telephone answering machine which records incoming messages and displays the number of accepted messages on an LED display The system should allow the telephone owner to dial in type a sequence of numbers identified as tones and have the recorded messages replayed over the phone
182. lution throughout the process Spiral Model of the Software Process Determine objectives alternatives and constraints Evalue altematives identify resolve risks Risk analysis Risk gt F an Opera Prototype 3 tional Prototype 2 protoype anaysig 0 type 1 Requirements plan Life cycle pla plan Developrent Integration and test plan Plan next phase ASP Develop verify nextdevel product Spiral Model Quadrants Objective Setting specific objectives for the phase are identified Risk Assessment and Reduction risks are assessed and activities put in place to reduce the key risks Development and Validation a development model for the system is chosen which can be any of the generic models Planning the project is reviewed and the next phase of the spiral is planned Models for Fundamental Process Activities Software specification requirements engineering Software development design and implementation Software verification and validation Software evolution Software Specification The process of establishing what services are required and the constraints on the system s operation and development Requirements Engineering Process e Feasibility technical and otherwise study e Requirements elicitation and analysis e Requirements specification documentation e Requirements validation The Requirements Engineering Process Feasibility study Feasibility report Requirements
183. m s environment and how expensive is it to maintain e Application assessment What is the quality of the application software system Business Process Assessment e Use a viewpoint oriented approach and seek answers from system stakeholders e Is there a defined process model and is it followed Do different parts of the organisation use different processes for the same function e How has the process been adapted e What are the relationships with other business processes and are these necessary e Is the process effectively supported by the legacy application software Environment Assessment Factor Questions Supplier Is the supplier is still in existence Is the supplier financially stable and stability likely to continue in existence If the supplier is no longer in business are the systems maintained by someone else Failure rate Does the hardware have a high rate of reported failures Does the support software crash and force system restarts Age How old is the hardware and software The older the hardware and support software the more obsolete it will be It may still function correctly but th ere could be significant economic and bu siness benefits to moving to more modern systems Performance Is the performance of the system adequate Do performance problems have a significant effect on system users Support What local support is required by the hardware and software If there requirements are hi
184. manager Responsible for the dynamic reconfiguration of the system software and hardware Hardware modules may be replaced and software upgraded without stopping the systems e Fault manager Responsible for detecting software and hardware faults and taking appropriate actions e g switching to backup disks to ensure that the system continues in operation Real time Executive Components Scheduling infomation Scheduler Process resource requirements Real time Interrupt clock handler Processes awaiting resources Avail able resource list Resource manager Released processes resources Processor list Executing process Process Priority The processing of some types of stimuli must sometimes take priority e Interrupt level priority Highest priority which is allocated to processes requiring a very fast response e Clock level priority Allocated to periodic processes Within these further levels of priority may be assigned Interrupt Servicing Control is transferred automatically to a pre determined memory location e This location contains an instruction to jump to an interrupt service routine Further interrupts are disabled the interrupt serviced and control returned to the interrupted process e Interrupt service routines MUST be short simple and fast Periodic Process Servicing e In most real time systems there will be several classes of periodic process e
185. mbedded systems that run on a single processor or on an integrated group of processors control systems real time systems Distributed systems where the system software runs on a loosely integrated group of processors linked by a network ATM systems Distributed Systems Virtually all large computer based systems are now distributed systems Processing is distributed over several computers rather than confined to a single machine Distributed software engineering is now very important Distributed System Characteristics Advantages Resource sharing hardware and software Openness resource extendibility Concurrency parallel processing Scalability up to capacity of network Fault tolerance potential Transparency ability to conceal distributed nature Distributed System Disadvantages Complexity no of factors affecting emergent properties Security multiple access points network eavesdropping Manageability heterogeneity Unpredictable responsiveness Issues in Distributed System Design Design issue Description Resource The resources in a distributed system are spread across different identification computers and a naming scheme has to be devised so that users can discover and refer to the resources that they need An example of such a naming scheme is the URL Uniform Resource Locator that is used to identify WWW pages If a meaningful and universally understood identification scheme is not used th
186. n if not A gt B and C lt D or not E gt F Simplified condition if A lt B and C gt D orE gt F Automatic Program Restructuring Program to be Restructured restructured program Analyser and Program graph builder generator Graph representation Restructuring Problems Problems with re structuring are Loss of comments Loss of documentation Heavy computational demands e Restructuring doesn t help with poor modularisation where related components are dispersed throughout the code e The understandability of data driven programs may not be improved by re structuring Program Modularisation e The process of re organising a program so that related program parts are collected together in a single module e Usually a manual process that is carried out by program inspection and re organisation Module Types Data abstractions A bstract data types where data structures and associated operations are grouped Hardware modules All functions required to interface with a hardware unit Functional modules Modules containing functions that carry out closely related tasks Process support modules Modules where the functions support a business process or process fragment Recovering Data Abstractions e Many legacy systems use shared tables and global data to save memory space Causes problems because changes have a wide impact in the system e Shared global data may be converted to o
187. n one or just afew sub systems 54 Availability include redundant components in the architecture e Maintainability use fine grain self contained components System Structuring Concemed with decomposing the system into interacting sub systems The architectural design is normally expressed as a block diagram presenting an overview of the system structure More specific models showing how sub systems share data are distributed and interface with each other may also be developed Examples follow Packing Robot Control System Object Arm Gripper identification conto ller controller system Packaging selection system Packing B Conveyor system controller The Repository Model e Sub systems must exchange info This may be done in two ways Shared data is held in a central database or repository and may be accessed by all sub systems Each sub system maintains its own database and passes data explicitly to other sub systems When large amounts of data are used the repository model of sharing is commonly used CASE Toolset Architecture Repository Model Advantages e Simple and efficient way to share large amounts of data locally e Sub systems which use data need not be concerned with how that data is produced and vice versa e Management activities such as backup access control and recovery are centralized e Sharing model is published as the repository schema Integra
188. n principle system requirements should state what the system should do and not how it should be designed e In practice however some design info may be incorporated since Sub systems may be defined to help structure the requirements Interoperability requirements may constrain the design Use of a specific design model may be a requirement More Potential Problems With Using Natural Language e Ambiguity the readers and writers of a requirement must interpret the same words in the same way NL is naturally ambiguous so this is very difficult e Over flexibility the same requirement may be stated in a number of different ways The reader must determine when requirements are the same and when they are different e Lacks of modularisation NL structures are inadequate to structure system requirements sufficiently Alternatives to NL Specification Notation Description Structured This approach depends on defining standard forms or natural templates to express the requirements specification language Design This approach uses a language like a programming description language but with more abstract features to specify the languages requirements by defining an operational model of the system Graphical A graphical language supplemented by text annotations is notations used to define the functional requirements for the system An early example of such a graphical language was SADT Ross 1977 Schoman and Ross
189. nal identification number The rail ticket is issued and their credit card account charged with its cost When the user presses the start button a menu display of potential destinations is activated along with a message to the user to select a destina tion Once a destination has been selected users are requested to input their credit card Its validity is checked and the user is then requested to input a personal identifier When the credit transaction has been validated the ticket is issued Activity Rewrite the above description using the structured approach described in this chapter Resolve the identified ambiguities in some appropriate way Activity Write system requirements for the above system using a Java based notation You may make any reasonable assumptions about the system Pay particular attention to specifying user errors Activity Using the technique suggested here where natural language is presented in a standard way write plausible user requirements for the following functions e An unattended petrol gas pump system that includes a credit card reader The customer swipes the card through the reader then specifies the amount of fuel required The fuel is delivered and the customer s account debited e The cash dispensing functioning a bank auto teller machine e The spell checking and correcting functioning a word processor 25 ONIMSANIDON A AYVMLIOS ONIMAANIDON A AYVMLIOS Activity Describe th
190. nctional approach is a natural way to implement transaction processing Design Description of an ATM INPUT loop repeat Print_input_message W lcome Please enter your card until Card_input Account_number Read_card Get_account_details PIN Account_balance Cash_available PROCESS if Invalid_card PIN then Retain_card Print Card retained please contact your bank else repeat Print_operation_select_message Button Get_button case Get_buttonis when Cash_only gt Dispense_cash Cash_available Amount_dispensed when Print_balance gt Print_customer_balance Account_balance when Statement gt Order_statement Account_number when Check_book gt Order_checkbook Account_number end case Print Press CONTINUE for more services or 9P to finish Button Get_button until Button STOP OUTPUT Eject_card Print Please take your card Update_account_information Account_number Amount_dispensed end loop Using Function oriented Design For some classes of system such as some transaction processing systems a function oriented approach may be a better approach to design than an object oriented approach Companies may have invested in CASE tools and methods for function oriented design and may not wish to incur the costs and risks of moving to an object oriented approach Legacy System Assessment Organisations that rely on legacy systems must choose
191. nd Modifying Existing Software Systems to Make them More Maintainable Objectives To explain why software re engineering is a cost effective option for system evolution e To describe the activities involved in the software re engineering process To distinguish between software and data re engineering and to explain the problems of data re engineering Topics Covered e Source code translation e Reverse engineering e Program structure improvement e Program modularisation e Datare engineering System Re engineering e Restructuring or re writing part or all of a legacy system without changing its functionality Applicable where some but not all sub systems of a larger system require frequent maintenance e Re engineering involves adding effort to make them easier to maintain The system may be re structured and re documented When to Re engineer e When system changes are mostly confined to part of the system then re engineer that part e When hardware or software support becomes obsolete When tools to support re structuring are available Re engineering Advantages e Reduced risk There is a high risk in new software development There may be development problems staffing problems and specification problems Reduced cost The cost of re engineering is often significantly less than the costs of developing new software Business Process Re engineering Concerned with re designing business processes to
192. ndards are an encapsulation of best practice e Reviews are the most widely used approach for assessing software quality e Software measurement gathers information about both the software process and the software product Product quality metrics should be used to identify potentially problematical components e There are no standardised and universally applicable software metrics Activity Explain why a high quality software process should lead to high quality software products Discuss possible problems with this system of quality management Activity What are the stages involved in the review of a software design Activity Briefly describe possible standards which might be used for The use of control constructs in C C OR Java e Reports which might be submitted for a term project in a university e The process of purchasing and installing a new computer Activity Explain why design metrics are by themselves an inadequate method of predicting design quality 125 ONIMSANIDONA AYVMLIOS ONIMAANIDON A AYVMLIOS Activity A colleague who is a very good programmer produces software with a low number of defects but consistently ignores organiza tional quality standards How should the managers in the organization react to this behaviour Notes 126 LESSON 35 PROCESS IMPROVEMENT Understanding Modelling and Improving the Softw are Process Objectives To explain the principles of software pro
193. needs experience and capabilities of the system users e Designers should be aware of people s physical and mental limitations e g limited short term memory and should recognise that people make mistakes e UI design principles underlie interface designs although not all principles are applicable to all designs Design Principles e User familiarity The interface should be based on user oriented terms and concepts rather than computer concepts For example an office system should use concepts such as letters documents folders etc rather than directories file identifiers etc e Consistency The system should display an appropriate level of consistency Commands and menus should have the same e Minimal surprise If acommand operates in a known way the user should be able to predict the operation of comparable commands e Recoverability 85 The system should provide some resilience to user errors and allow the user to recover from errors This might include an undo facility confirmation of destructive actions soft deletes etc e User guidance Some user guidance such as help systems on line manuals etc should be supplied e User diversity Interaction facilities for different types of user should be supported For example some users have seeing difficulties and so larger text should be available Format command punctuation should be similar etc User system Interaction Two problems must be ad
194. neering Roughly 60 of costs are development costs 40 are testing costs For custom software evolution costs often exceed development costs Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability Distribution of costs depends on the development model that is used What are Softw are Engineering Methods Structured approaches to software development which include system models notations rules design advice and process guidance Model Descriptions Descriptions of graphical models which should be produced Rules Constraints applied to system models Recommendations Advice on good design practice Process Guidance What activities to follow What is Case Computer aided Software Engineering Software systems which are intended to provide automated support for software process activities CASE systems are often used for method support Upper CASE Tools to support the early process activities of requirements and design Low er CASE Tools to support later activities such as programming debug ging and testing What are The Attributes of Good Software The software should deliver the required functionality and performance to the user and should be maintainable depend able and usable Maintainability Software must evolve to meet changing needs Dependability Software must be trustworthy Efficiency Software should not make wast
195. ng Consider each risk and develop a strategy to manage that risk Avoidance strategies the probability that the risk will arise is reduced Minimisation strategies the impact of the risk on the project or product is reduced Contingency plans if the risk arises contingency plans are plans to deal with that risk 16 Risk Management Strategies Risk Strategy Organisational Prepare a briefing document for senior management showing how the project is financial problems making a very important contribution to the goals of the business Recruitment Alert customer of potential difficulties and the possibility of delays investigate problems buying in components Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other s jobs Defective Replace potentially defective components with bought in components of known components reliability Requirements Derive traceability information to assess requirements change impact maximise changes information hiding in the design Organisational Prepare a briefing document for senior management showing how the project is restructuring making a very important contribution to the goals of the business Database Investigate the possibility of buying a higher performance database performance Underestimated Investigate buying in components investigate use of a program generator development time Ris
196. ns pressures rainfall collect summarise thermometer win dSpeed pressure win dDirection height test ae test mie WeatherStation reportWeather calibrate instruments test startup instruments shutdown instrum ents Other Objects And Object Refinement Use domain knowledge to identify more objects operations and attributes Weather stations should have a unique identifier Weather stations are remotely situated so instrument failures have to be reported automatically Therefore attributes and operations for self checking are required e Active or passive objects Instrument objects are passive and collect data on request rather than autonomously This introduces flexibility how at the expense of controller processing time Are any active objects required 4 Develop Design Models Design models show the relationships among objects and object classes e Static models describe the static structure of the system in terms of object and object class relationships e Dynamic models describe the dynamic interactions among objects Examples of Design Models e Sub system models show logical groupings of objects into coherent sub systems static e Sequence models show the sequence of object interactions associated with system uses dynamic e State machine models show how individual objects change their state in response to events dynamic Other models include use c
197. nst which systems can be evaluated The OSI Open System Interconnection model is a layered model for communication systems in particular data processing point of sale applications OSI Reference M odel cs on Key Points The software architect is responsible for deriving a structural system model a control model and a sub system decomposition model Large systems rarely conform to a single architectural model System decomposition models include the repository model client server model and abstract machine model Control models include centralized control and event driven models Modular decomposition models include data flow and object models e Domain specific architectural models are abstractions over an application domain They may be constructed by abstracting from existing systems or they may be idealized reference models Activity Explain why it may be necessary to design the system architec ture before the specifications are written Activity Construct a table showing the advantages and disadvantages of the different structural models discussed in this chapter 58 Activity Giving reasons for your answer suggest an appropriate structural model for the following systems e An automated ticket issuing system used by passengers at a railway station e A computer controlled video conferencing system which allows video audio and computer data to be visible to several participants at th
198. o model generality and flexibility in service provision e C S systems seem to be a more natural model for most systems They reflect many human service transactions CORBA Common Object Request Broker Architecture e International standards for an O bject Request Broker O RB middleware to manage communications between distributed objects Several implementation of CORBA are available Unix and MS OS s Defined by the Object Management Group gt 500 companies including Sun HP IBM DCOM Distributed Component Object Model is an alternative standard developed and implemented by Microsoft Components of The OMG Vision of a Distributed Application e Application objects designed and implemented for this application 63 e Domain specific objects defined by the O MG e g finance insurance healthcare Fundamental CORBA distributed computing services such as directories and security management Horizontal facilities such as user interface facilities used in many different applications COBRA Application Structure Horizontal CORBArfacilities Application objects CORBA services Major Elements of the CORBA Standards e An application object model where objects encapsulate state and have a well defined language neutral interface defined in an IDL interface definition language An object request broker O RB that locates objects providing services sends service requests and re
199. o these stimuli For each stimulus and response identify the timing constraints Aggregate the stimulus and response processing into concurrent processes response Design algorithms to process each class of stimulus and response These must meet the given timing requirements are started in time to meet their deadlines e Integrate using a real time executive or operating system Timing Constraints e May require extensive simulation and experiment to ensure that these are met by the system May mean that certain design strategies such as object oriented design cannot be used because of the additional overhead involved May mean that low level programming language features have to be used for performance reasons State Machine Modelling The effect of a stimulus in a real time system may trigger a transition from one state to another e Finite state machines can be used for modelling real time systems e However FSM models lack structure Even simple systems can have a complex model The UML includes notations for defining state machine models A process may be associated with each class of stimulus and Design a scheduling system which will ensure that processes Microw ave Oven State Machine jo get number exit settime T clos Real time Programming Hard real time systems may have to programmed in assembly language to ensure that deadlines are met Languages such
200. ocess and Product Quality Process Analysis and Modelling Process Measurement the SEI Process Maturity Model and Process Classification Evolution Legacy Systems Structures Design and Assessment Software Change Program Evolution Dynamics Software Maintenance Architectural Evolution Software Re Engineering Source Code Translation Reverse Engineering Program Structure Improvement Program Modularization Data Re Engineering Configuration Management Suggested Readings 1 Software Engineering An Engineering Approach by J F Peters and W Pedrycz Publisher John Wiley and Sons 2 Software Engineering A Practitioner s Approach by Roger Pressman Publisher McGraw Hill 3 Fundamentals of Software Engineering by Ghezzi Jayazeri and Mandrioli Publisher Prentice Hall 4 Software Engineering Fundamentals by Ali Behforooz and Frederick J Hudson Publisher Oxford University Press COURSE OVERVIEW Software systems are now ubiquitous Virtually all electrical equipment now includes some kind of software software is used to help run manufacturing industry schools and universities health care finance and government many people use software of different kinds for entertainment and education The specification development management and evolution of these software systems make up the discipline of software engineering Even simple software systems have a high inherent complexity so engineering principles have to be used in th
201. oftware Business policies and rules Runs on Constrains Business processes Application data System hardware Layered M odel Socio technical system Business processes Application softw are Support so ftw are System Change e In principle it should be possible to replace a layer in the system leaving the other layers unchanged e In practice this is usually impossible 132 e Changing one layer introduces new facilities and higher level layers must then change to make use of these e Changing the software may slow it down so hardware changes are then required e It is often impossible to maintain hardware interfaces because of the wide gap between mainframes and client server systems Legacy Application System Program 2 Database describes management system Logical and physical data models Transaction Processing Account queries and updates Serialised transactions Teleprocessing monitor Accounts database ATM s and terminals Legacy Data The system may be file based with incompatible files The change required may be to move to a database management system In legacy systems that use a DBMS the database management system may be obsolete and incompatible with other DBMSs used by the business The teleprocessing monitor may be designed for a particular DB and mainframe Changing to anew DB may require a new TP monitor Legacy Syst
202. ol and data acquisition systems Topics Covered e Systems design e Real time executives Monitoring and control systems e Data acquisition systems Real time Systems e Systems which monitor and control their environment e Inevitably associated with hardware devices Sensors Collect data from the system environment Actuators Change in some way the system s environment Time is critical Real time systems MUST respond within specified times Definition e A real time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced e A soft real time system is a system whose operation is degraded if results are not produced according to the specified timing requirements e A hard real time system is a system whose operation is incorrect if results are not produced according to the timing specification Stimulus Response Systems Given a stimulus the system must produce a response within a specified time e Periodic stimuli Stimuli which occur at predictable time intervals For example a temperature sensor may be polled 10 times per second e A periodic stimuli Stimuli which occur at unpredictable times For example a system power failure may trigger an interrupt which must be processed by the system Architectural Considerations e Because of the need to respond to timing demands made by diff
203. olvement Very high 1 Architecture risk resolution No risk analysis V Low 5 Team cohesion new team nominal 3 Process maturity some control nominal 3 Scale factor is therefore 1 17 Exponent Scale Factors Scale factor Explanation Precedertedress Reflects the previousexparienceof the arganisation with this type of project Very low meansno previous experience Extra high means that the organisation is completely familiar with this application danain Devdopment Reflects the degree of flexibility in the amp velopment flexibility process Very low means a pescribedproess is used Extra high mears that the client only sets general gods Architecture risk Reflects the extent of risk analysis carried out Very low resdution means littk analysis Extra high meansa complete a thoroughrisk analysis Team coheson Reflects how well the devdopment team know ach other and work together Very low mears very difficult interactions Extra high means an integrated and effective team with nocommunication problems Process maturity Reflects the process maturity of the organisation The computation this value depends on the CMM Maturity Quesionnare but an estimate can be ahieved by subtracting the CMM proess maturity levd from 5 Multipliers Product attributes Concerned with required characteristics of the software product being developed e Computer attributes Constraints imposed on the software by the h
204. omponents into an executable system e Different systems are built from different combinations of components e Invariably supported by automated tools that are driven by build scripts System Building Problems Do the build instructions include all required components When there are many hundreds of components making up a system it is easy to miss one out This should normally be detected by the linker e Is the appropriate component version specified A more significant problem A system built with the wrong version may work initially but fail after delivery e Are all data files available The build should not rely on standard data files Standards vary from place to place e Are data file references within components correct Embedding absolute names in code almost always causes problems as naming conventions differ from place to place e Is the system being built for the right platform Sometimes must build for a specific OS version or hardware configuration e Is the right version of the compiler and other software tools specified Different compiler versions may actually generate different code and the compiled component will exhibit different behaviour System Building System builder Version management Source code Object code components component versions Executable system System Representation e Systems are normally represented for building by specifying the fil
205. on one roject may give the opportunitpf more profit later he experience gained may allow new products to bel eveloped Factor Market opportunity Cost estimate uncertainty f an organisation is unsure of its cost estimate it ay increase its price by some contingency over and bbove its normal profit customer may bewilling to allow the developer to etain ownership of the source code and reuse it in ther projects The price charged may then be less han if thesoftware source code is handed over to the kustomer Ifthe requirements are likely to change an organisationmay lower its price to win a contract After the contract is awarded high prices may be charged for changes to the requirements Developers in financial difficulty may lower their price to gain a contract It is better to make a small profit or break even than to go out of business Contractual terms Requirements volatility Financial health Programmer Productivity e A measure of the rate at which individual engineers involved in software development produces software and associated documentation Not quality oriented although quality assurance is a factor in productivity assessment Essentially we want to measure useful functionality produced per time unit Productivity Measures e Size related measures based on some output from the software process This may be lines of delivered source code object code instructions etc Function relat
206. oper skills required e Maintenance problems Continual change tends to corrupt system structure so long term maintenance is expensive Contractual problems No system requirements specification to serve as basis for contract Incremental Development Revisited e System developed and delivered in increments after establishing an overall architecture e Users experiment with delivered increments while others are being developed e Intended to combine advantages of prototyping with a more manageable process and maintainable system structure Incremental Development Process Design system architecture Throw aw ay Prototyping e Used to reduce requirements risk e Initial prototype is developed from outline requirements delivered for experiment and modified until risk is acceptably low Outline requirements Reusable components Develop software Throw away Prototype Delivery Developers may be pressurized to deliver a throw away prototype as the final system e This is very problematic It may be impossible to meet non functional requirements The prototype is almost certainly undocumented The system may be poorly structured and therefore difficult to maintain Normal quality standards may not have been applied Prototypes AS Specifications e Some parts of the requirements e g safety critical functions may be impossible to prototype and so don t appear in the specification 44
207. or large projects and M is a multiplier reflecting product process and people attributes e Most commonly used product attribute for cost estimation is code size e Most models are basically similar but with different values for A B and M Estimation Accuracy e The size of a software system can only be known accurately when it is finished Several factors influence the final size Use of COTS and components Programming language Distribution of system e As the development process progresses then the size estimate becomes more accurate Estimate Uncertainty 4x Feasibility Requirements Design Code Delivery 0 5x 0 25x The COCOMO Model e An empirical model based on project experience Well documented independent model which is not tied to a specific software vendor Long history from initial version published in 1981 COCO MO 81 through various instantiations to COCOMO 2 e COCOMO 2 takes into account different approaches to software development reuse etc COCOMO 81 Project Formula Description complexity Simple PM 2 4 KDSI 05 x M Well understood applications developed by small teams Moderate PM 3 0 KDSI 2 x M More complex projects where team members may have limited experience of related systems Complex projects where the software is part of a strongly coupled complex of hardware software regulations and operational procedures Embedded PM 3 6 KDSI 20 xM C
208. ory conditions AFTER program execution Language first order predicate calculus Predicates X gt 4 Connectives amp V NOT Universal and existential quantifiers for every there exists Rules of inference if A amp A B then B Example 1 Sort a non empty array LIST 1 N into increasing order Pre cond N gt 1 Post cond For Everyi 1 lt i lt N 1 LIST i lt LIST it 1 amp PERM LIST LIST 51 ONIMSANIDON A AYVMLAIOS Example 2 Search a non empty ordered array LIST 1 N for the value stored in KEY If present set found to true and J to an index of LIST which corresponds to KEY Otherwise set FOUND to false Pre cond N gt 1 amp LIST is in increasing order V LIST is in decreasing order Exercise express the ordered predicate above FORMALLY Post cond FOUND amp There Exists i 1 lt i lt N J i amp LIST J Key V NOT FOUND amp For Everyi 1 lt i lt N LIST i KEY amp UNCH LIST KEY Key Points e Formal system specification complements informal specification techniques Formal specifications are precise and unambiguous They remove areas of doubt in a specification e Formal specification forces an analysis of the system requirements at an early stage Correcting errors at this stage is cheaper than modifying a delivered system Formal specification techniques are most applicable in the development of critical
209. ould be maintained as an organisational resource e Once a measurement database has been established comparisons across projects become possible Product Measurement Process Choose measurements tobe made Analyse anomalous components Select components to be assessed Identify anomalous measurements Measure compaent char acteristics Data Collection A metrics programme should be based on a set of product and process data Data should be collected immediately not in retrospect and if possible automatically e Three types of automatic data collection Static product analysis Dynamic product analysis Process data collation 123 Automated Data Collection Instrumented software system Data Accuracy e Don tcollect unnecessary data The questions to be answered should be decided in advance and the required data identified Tell people why the data is being collected It should not be part of personnel evaluation Don t rely on memory Collect data when it is generated not after a project has finished Product Metrics e A quality metric should be a predictor of product quality e Classes of product metric Dynamic metrics which are collected by measurements made of a program in execution Static metrics which are collected by measurements made of the system representations Dynamic metrics help assess efficiency and reliability static metr
210. p bottom gt top Binary search flow graph 99 Independent Paths e 12 378 9 e 12 3 46 7 2 e 1 2 3 4 5 7 2 e 1 2 3 4 6 7 2 8 9 Test cases should be derived so that all of these paths are executed e A dynamic program analyser may be used to check that paths have been executed Integration Testing Tests complete systems or subsystems composed of integrated components e Integration testing should be black box testing with tests derived from the specification e Main difficulty is localising errors e Incremental integration testing reduces this problem Incremental Integration Testing Test sequence Test sequence Test sequence Approaches to Integration Testing Top down testing Start with high level system and integrate from the top down replacing individual components by stubs where appropriate e Bottom up testing Integrate individual components in levels until the complete system is created e In practice most integration involves a combination of these strategies Top down Testing Bottom up Testing Test drivers Level N N Level N sequence AVA OY divers team N Level N 1 Level N 1 Testing Approaches e Architectural validation Top down integration testing is better at discovering errors in the system architecture e System demonstration Top down integration testing allows a limited demonstration at an early stage in the development e Test implementat
211. pendent The weaker the type checking by the compiler the larger the checklist e Examples initialisation constant naming loop termination array bounds etc Inspection Checks Inspection check Are all program variables initialised before their values are used Have all constants been named Should the lower bound of arrays be 0 1 or something else Should the upper bound of arrays be equal to the size of the array or Size 1 If character strings are used is a delimiter explicitly assigned For each conditional statement is the condition correct Is each loop certain to terminate Are compound statements correctly bracketed In case statements are all possible cases accounted for Are all input variables used Are all output variables assigneda value before they are output Do all function and procedure calls have the correct number of parameters Do formal and actual parameter types match Are the parameters in the right order If components access shared memory do they have the same model of the shared memory structure If a linked structure is modified have all links been correctly reassigned If dynamic storage is used has space been allocated correctly Is space explicitly de allocated after it required Have all possible error conditions been taken account Fault class Data faults Control faults Input output faults Interface faults Stora
212. pensive Special purpose programs have to be written to carry out the conversion The Data Re engineering Process Entity name modification re formatting Literal Default value Data replacement conversion conversion Data definition Validation rule re ordering modification Key Points The objective of re engineering is to improve the system structure to make it easier to understand and maintain e The re engineering process involves source code translation reverse engineering program structure improvement program modularisation and data re engineering e Source code translation is the automatic conversion of program in one language to another e Reverse engineering is the process of deriving the system design and specification from its source code Program structure improvement replaces unstructured control constructs with while loops and simple conditionals Program modularisation involves reorganisation to group related items e Data re engineering may be necessary because of inconsistent data management 146 Activity Under what circumstances do you think that software should scrapped and rewritten rather than re engineered Activity Write a set of guidelines that may be used to help find modules in an unstructured program Activity What problems might arise when converting data form one type of database management system to another e g hierarchi cal to relational or relational
213. port summarise send report reply report acknowledge Weather Station Testing e Thread of methods executed CommsController request WeatherStation report WeatherD ata summarise e Inputs and outputs Input of report request with associated acknowledge and a final output of a report Can be tested by creating raw data and ensuring that it is summarised properly Use the same raw data to test the Weather D ata object Testing Workbenches Testing is an expensive process phase Testing workbenches provide a range of tools to reduce the time required and total testing costs Most testing workbenches are open systems because testing needs are organisation specific Difficult to integrate with closed design and analysis workbenches A Testing Workbench Test daa generator Test Test results predictions File comparator Spec fication Program being tested Execution report Test results report Testing Workbench Adaptation Scripts may be developed for user interface simulators and patterns for test data generators Test outputs may have to be prepared manually for comparison e Special purpose file comparators may be developed Key Points e Test parts of a system which are commonly used rather than those which are rarely executed e Equivalence partitions are sets of test cases where the program should behave in an equivalent way e Black box testing is
214. process undertaken in parallel with the abstract specification of sub systems The output of this process is the software architecture The Software Design Process Requiements specificaion Design actvities Arhitectual Abstiact Interface Component design specificdion design design System Softvare Interface Component specificaion specificaion ae Algorithm si ructue design design Daa structue specificaion Algorithm specificaion architectue specificaion Design poducts A dvantages of explidt architecture design and documentation Bass e Stakeholder communication the architecture may be used as a focus of discussion by system stakeholders e System analysis the feasibility of meeting critical non functional requirements e g performance reliability maintainability can be studied early on e Large scale reuse the architecture may be reusable across a range of systems with similar requirements Architectural Design Process e System structuring the system is decomposed into major sub systems and communication e g data sharing mechanisms are identified Control modelling a model of the control relationships between the sub systems is established Modular decomposition the identified sub systems are decomposed into lower level modules components objects etc Terminology Issues Modular decomposition is sometimes called h
215. r Style Messages should be positive rather than negative They should use the active rather than the passive mode of address They should never be insulting or try to be funny Culture Wherever possible the designer of messages should be familiar with the culture of the country where the system is sold There are distinct cultural differences between Europe Asia and America A suitable message for one culture might be unacceptable in another 88 Nurse Input of a Patient s Name Please type the patient name in the bo x then click on OK Qe System and User oriented Error Messages 7 User oriented error message System oriented error message Patient J Bates is not registered Cic kon Patientsf ora ist of registered patients Clik on Rey to re input a patient name Clic on Helpor more iofmation Help System Design Help means help I want information Help means HELP I m in trouble Both of these requirements have to be taken into account in help system design Different facilities in the help system may be required Help Information e Should not simply be an on line manual e Screens or windows don t map well onto paper pages e The dynamic characteristics of the display can improve information presentation People are not so good at reading screen as they are text Help System Use Multiple entry points should be provided so that the user can get into the help system
216. r Java Beans Reusable Component Composition Reusable software components Component composition framework Control and integration code Compound Documents e For some applications a prototype can be created by developing a compound document Executable prototype e This is a document with active elements such as a spreadsheet that allow user computations Each active element has an associated application which is invoked when that element is selected The document itself is the integrator for the different applications Application Linking in Compound Documents Compound document T Spreadsheet Audio player W ord processor 45 Visual Programming Scripting languages such as Visual Basic support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items e A large library of components exists to support this type of development These may be tailored to suit the specific application requirements Visual Programming With Reuse Hypertext display component General Date component File Edit Views Layout 12th January 2000 Range checking saipt Draw canvas component User prompt component Tree display component Problems With Visual Development e Difficult to coordinate team based development No explicit system architec
217. r managers may feel that they are too important to use a keyboard This may limit the type of system interface used e Managerial responsibilities Managers may have no uninterrupted time when they can leam to use the system e Organizational resistance Middle managers who will be made redundant may deliberately provide misleading or incomplete information so that the system will fail Ethnography e A social scientists spends considerable time observing and analysing how people actually work People do not have to explain or articulate what they do Social and organizational factors of importance may be observed e Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models Focused Ethnography Developed during a project studying the air traffic control process Combines ethnography with prototyping Prototype development raises issues which focus the ethnographic analysis Problem with ethnography alone it studies existing practices which may not be relevant when a new system is put into place Requirements Validation e Concerned with whether or not the requirements define a system that the customer really wants Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times that of fixing an error during implementation Requirements Checking e Validity Does the sy
218. rding to their specific function Process perspective tools are classified according to process activities that are supported Integration perspective CASE systems are classified according to their breadth of support for the software process CASE Integration Tools support individual process tasks such as design consistency checking text editing etc Workbenches support a process phase such as specification or design Normally include a number of integrated tools Environments support all or a substantial part of an entire software process Normally include several integrated work benches Tools Workbenches Environments ee environments environments Analysis and design Single method workbenches General purpose workbenches Language specific workbenches Key Points Software processes are the activities involved in producing and evolving a software system They are represented in a software process model Fundamental activities are specification design and implementa tion validation amp verification and evolution Generic models are very general process models representing different approaches to development Iterative process models describe the software process as a cycle of activities Requirements engineering is the process of establishing what services are required and the constraints on the system s operation and development Design and implementation processes
219. rds Design review form Document naming standards Procedure header format Ada programming style standard Project plan approval process Project plan format Change control process l Change request form Test recording process Problems with Standards Not seen as relevant and up to date by software engineers Involve too much bureaucratic form filling Unsupported by software tools so tedious manual work is involved to maintain standards Standards Development e Involve practitioners in development Engineers should understand the rationale underlying a standard e Review standards and their usage regularly Standards can quickly become outdated and this reduces their credibility amongst practitioners e Detailed standards should have associated tool support Excessive clerical work is the most significant complaint against standards Documentation Standards Particularly important documents are the tangible manifestation of the software e Documentation process standards How documents should be developed validated and main tained Document standards Concerned with document contents structure and appearance Document interchange standards How documents are stored and interchanged between different documentation systems Documentation Process Review Incorporate a Re draft draft document review comments Create initial draft Stage 1 Creation Approved document Proofread
220. ree different types of non functional requirement which may be placed on a system Give examples of each of these types of requirement Activity Write a set of non functional requirements for the ticket issuing system described above setting out its expected reliability and its response time Activity You have taken a job with a software user who has contracted your previous employer to develop a system for them You discover that your compan7y s interpretation of the require ments is different form the interpretation taken by your previous employer Discuss what you should do in such a situation You know that the costs to your current employer will increases in the ambiguities are not resolved Y ou have also a responsibility of confidentiality to your previous employer 26 LESSON 8 AND 9 REQUIREM ENTS ENGINEERING PROCESS Objectives e To describe the principal requirements engineering activities e To introduce techniques for requirements elicitation and analysis e To describe requirements validation e To discuss the role of requirements management in support of other requirements engineering processes Topics Covered e Feasibility studies e Requirements elicitation and analysis e Requirements validation e Requirements management Requirements Engineering Processes e The processes used for RE vary widely depending on the application domain the people involved and the organization developing the requirements
221. refore not just concerned with reducing defects but also with other product qualities Quality Management Activities e Quality assurance Establish organisational procedures and standards for quality e Quality planning Select applicable procedures and standards for a particular project and modify these as required e Quality control Ensure that procedures and standards are followed by the software development team e Quality management should be separate from project management to ensure independence Quality Management and Software Development Software development DI D2 D3 D4 D5 cess Quality management yyy ovo yY V_ Standards and Quality Quality review reports procedures plan ISO 9000 e International set of standards for quality management e Applicable to a range of organisations from manufacturing to service industries ISO 9001 applicable to organisations which design develops and maintains products e ISO 9001 is a generic model of the quality process must be instantiated for each organisation uality system Design control Purchasing Management responsibility Control of non conforming products Handling storage packaging and deliver Purchaser supplied products Process control Inspection and test equipment Contract review Product identification and traceabilit Inspection and test status Corrective action Document control Quality records Internal qu
222. rned with cost effective software development FAQs About Software Engineering What is software What is software engineering What is the difference between software engineering and computer science What is the difference between software engineering and system engineering What is a software process What is a software process model What are the costs of software engineering What are software engineering methods What is CASE Computer Aided Software Engineering What are the attributes of good software What are the key challenges facing software engineering What is Softw are Computer programs and associated documentation Software products may be developed for a particular customer or may be developed for a general market Software products may be e Generic developed to be sold to a range of different customers e Bespoke custom developed for a single customer according to their specification What is Software Engineering Software engineering is an engineering discipline which is concerned with all aspects of software production Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and tech niques depending on the problem to be solved the development constraints and the resources available What is The Difference Betw een Software Engineering and Computer Science Computer science is concerned with theory and fundamentals software engineering i
223. roup members work closely together so inhibitions caused by ignorance arereduced Team members learn from each other and get to know each other s work Ego less programming where members strive to improve each other s programs can be practised Developing Cohesiveness Cohesiveness is influenced by factors such as the organisational culture and the personalities in the group e Cohesiveness can be encouraged through Social events Developing a group identity and territory 106 Explicit team building activities e Openness with information is a simple way of ensuring all group members feel part of the group Group Loyalties Group members tend to be loyal to cohesive groups Groupthink is preservation of group irrespective of technical or organizational considerations e Management should act positively to avoid groupthink by forcing external involvement with each group Group Communications e Good communications are essential for effective group working e Information must be exchanged on the status of work design decisions and changes to previous decisions e Good communications also strengthens group cohesion as it promotes understanding e Status of group members Higher status members tend to dominate conversations e Personalities in groups Too many people of the same personality type can be a problem e Sexual composition of group Mixed sex groups tend to communicate better Communication channel
224. rs Multipliers reflect the capability of the developers the non functional requirements the familiarity with the development platform etc RCPX product reliability and complexity RUSE the reuse required PDIF platform difficulty PREX personnel experience PERS personnel capability SCED required schedule FCIL the team support facilities PM reflects the amount of automatically generated code 115 Post architecture Level e Uses same formula as early design estimates e Estimate of size is adjusted to take into account Requirements volatility Rework required to support change Extent of possible reuse Reuse is non linear and has associ ated costs so this is not a simple reduction in LOC ESLOC ASLOC AA SU 0 4DM 0 3CM 0 3IM 100 E SLOC is equivalent number of lines of new code ASLOC is the number of lines of reusable code which must be modified DM is the percentage of design modified CM is the percentage of the code that is modified IM is the percentage of the original integration effort required for integrating the reused software SU is a factor based on the cost of software understanding AA isa factor which reflects the initial assessment costs of deciding if software may be reused The Exponent Term This depends on 5 scale factors see next slide Their sum 100 is added to 1 01 e Example Precedent ness new project 4 Development flexibility no client inv
225. rted which affect the way in which many customers use the system it may be necessary to issue a fault repair release However minor system faults may be repaired by issuing patches often distributed over the Internet that can be applied to the current release of the system Lehman s fifth law This suggests that the increment of functionality which is included see Chapter 27 in each release is approximately constant Therefore if there has been a system release with significant new functionality then it may have to be followed by a repair release Competition A new system release may be necessary because a competing product is available Marketing The marketing department of an organisation may have made a requirements commitment for releases to be available at a particular date Customer change For customised systems customers may have made and paid for a proposals specific set of system change proposals and they expect a system release as soon as these have been implemented Release Creation e Release creation involves collecting all files and ocumentation required to create a system release Configuration descriptions have to be written for different hardware and installation scripts have to be written The specific release must be documented to record exactly what files were used to create it This allows it to be re created if necessary System Building e The process of compiling and linking software c
226. rts requirenents Scheduling Problems e Estimating the difficulty of problems and hence the cost of developing solutions is hard e Progress is generally not proportional to the number of people working on a task e Adding people to a late project can make it later due to coordination overhead e The unexpected always happens Always allow for different contingencies in planning Bar Charts and Activity Networks e Graphical notations are often used to illustrate project schedules e Activity charts a k a PERT charts show task dependencies durations and the critical path e Bar charts a k a GANTT charts generally show resource e g people assignments and calendar time Program Evaluation and Review Technique Task Durations and Dependencies Task Duration days Dependencies Tl 8 T2 15 T3 15 T1 M1 T4 10 T5 10 T2 T4 M2 T6 5 T1 T2 M3 T7 20 T1 M1 T8 25 T4 M5 15 T3 T6 M4 15 T5 T7 M7 7 T9 M6 10 T11 M8 11 8 99 5 9 99 18 7 99 14 Activity Timeline 11 7 18 7 25 7 1 8 8 8 15 8 22 8 29 8 5 9 12 9 19 9 2 E E ee ee a 7 mm ea r ERRANEN 5 M M3 pann M2 d T6 a i T5 a pF o O a Fa E 4 1 4 UN 197 29 B 8B 198 2B BB 58 179 199 1897 25 18 158 22 8 29 8 50 47 IIT 197 29 B 8B 198 2B WB 58 179 199 19 9 Staff Allocation T SA T n a 15 Risk Management
227. rts and 3GL modules e They can therefore be estimated at an early point in the development process At this stage it is very difficult to estimate the number of lines of code in a system Productivity Estimates Real time embedded systems 40 160 LOC P month e Systems programs 150 400 LOC P month e Commercial applications 200 800 LOC P month In object points productivity has been measured between 4 and 50 object points month depending on tool support and developer capability Factors Affecting Productivity Factor Description Application domain Knowledge of the application domain is essential for experience effective software development Engineers whalread understand a domain are likely to be the most roductive The development process used can havea significant effect on productivity This is covered in Chapter 31 The larger a project the more time required for team communications Less time is available for development so individual productivity is reduced Good support technology such as CASE tools supportive configuration management systems etc can improve productivity As discussed in Chapter 28 a quiet working environment with private work areas contributes to Process quality Project size Technology support Working environment improved productivity Quality and Productivity e All metrics based on volume unit time are flawed because they do not take qu
228. ruments shutdown instruments e Test cases are needed for all operations e Use a state model to identify state transitions for testing e Examples of testing sequences Shutdown Waiting Shutdown Waiting Calibrating Testing Transmitting Waiting Waiting Collecting Waiting Summarising Transmitting Waiting Object Integration e Levels of integration are less distinct in object oriented systems e Cluster testing is concerned with integrating and testing clusters of cooperating objects e Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters Approaches to Cluster Testing e Use case or scenario testing Testing is based on user interactions with the system Has the advantage that it tests system features as experienced by users Thread testing Tests the systems response to events as processing threads through the system e Object interaction testing Tests sequences of object interactions that stop when an object operation does not call on services from another object Scenario based Testing e Identify scenarios from use cases and supplement these with interaction diagrams that show the objects involved in the scenario Consider the scenario in the weather station system where a report is generated 101 Collect Weather Data request report CommsController W _eatherStation W eatherData acknowledge re
229. ry Software e Rather than think of separate development and maintenance phases evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime The Maintenance Process Change Impact Systemrelease Change System requests analysis planning implementation release Perfective Adaptive Corrective maintenance maintenance maintenance Change Requests e Change requests are requests for system changes from users customers or management e In principle all change requests should be carefully analysed as part of the maintenance process and then implemented e In practice some change requests must be implemented urgently Fault repair Changes to the system s environment Urgently required business changes Change Implementation Requirements analysis Requirements updating 140 Emergency Repair Modify source code Deliver modified system Maintenance Prediction e Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs Change acceptance depends on the maintainability of the components affected by the change Implementing changes degrades the system and reduces its maintainability Maintenance costs depend on the number of changes and costs of change depend on maintainability Maintenance Prediction What parts of the system will be the most ex pensive
230. ry system when a group of people arrange a meeting support the timetabling of meetings and appointments across a group of co workers When an appointment is to be made which involves a number of people the system finds a common slot in each of their diaries and arranges the appointment for that time If no common slots are available it interacts with the users to rearrange their personal diaries to make room fort the appointment e A petrol gas station is to be set up for fully automated operation D erivers swipe their credit card through a reader connected to the pump the card is verified by communication with a credit company computer and a fuel limit established The driver may then take the fuel required when fuel delivery is complete and the pump hose is returned to its holster the driver s credit card account is debited with the cost to the furl taken The credit card is returned after debiting If the card is invalid it is returned buy the pump before fuel is dispensed 73 ONIYSANIDONA AYVMLAIOS LESSON 21 AND 22 REAL TIME SOFTWARE DESIGN Designing Embedded Softw are Systems Whose Behaviour is Subject to Timing Constraints Objectives To explain the concept of a real time system and why these systems are usually implemented as concurrent processes e To describe a design process for real time systems To explain the role of a real time executive To introduce generic architectures for monitoring and contr
231. s e Questions Questions about areas of uncertainty related to the goals You need process knowledge to derive these e Metrics Measurements to be collected to answer the questions The Software Engineering Institute US Defence Dept funded institute associated with Carnegie Mellon Mission is to promote software technology transfer particularly to defence contractors Maturity model proposed in mid 1980s refined in early 1990s Work has been very influential in process improvement The SEI Process Maturity Model Level 5 Optimizing Level 4 Manag ed Level 3 Defined Level 2 Repeatable Level 1 Initial Maturity M odel Levels e Initial Essentially uncontrolled e Repeatable Product management procedures defined and used Defined Process management procedures and strategies defined and used e Managed Quality management strategies defined and used e Optimising Process improvement strategies defined and used Key Process Areas Optimizing Process change management Technology change management Defect prevention Managed Software quality management Quantitative process management Defined Peer reviews Intergroup coordination Software product engineering Integrated software management Training programme Organization process definition Organization process focus Repeatable Softw are confi guration management Software quality assurance Software subcontract management Soft
232. s e Software processes are complex and process models cannot effectively represent how to handle exceptions Several key people becoming ill just before a critical review A complete failure of a communication processor so that no e mail is available for several days Organisational reorganisation A need to respond to an unanticipated request for new proposals e Under these circumstances the model is suspended and managers use their initiative to deal with the exception Process Measurement e Wherever possible quantitative process data should be collected However where organisations do not have clearly defined process standards this is very difficult as you don t know what to measure A process may have to be defined before any measurement is possible e Process measurements should be used to assess process improvements 128 But this does not mean that measurements should drive the improvements The improvement driver should be the organizational objectives Classes of Process Measurement Time taken for process activities to be completed E g Calendar time or effort to complete an activity or process e Resources required for processes or activities E g Total effort in person days e Number of occurrences of a particular event E g Number of defects discovered Goal Question Metric Paradigm e Goals What is the organisation trying to achieve The objective of process improvement is to satisfy these goal
233. s Communications channelled though a central coordinator tend to be ineffective Group Organisation Software engineering group sizes should be relatively small lt 8 members e Break big projects down into multiple smaller projects Small teams may be organised in an informal democratic way Chief programmer teams try to make the most effective use of skills and experience Democratic Team Organisation e The group acts as a whole and comes to a consensus on decisions affecting the system The group leader serves as the external interface of the group but does not allocate specific work items e Rather work is discussed by the group as a whole and tasks are allocated according to ability and experience This approach is successful for groups where all members are experienced and competent Extreme Programming Groups e Extreme programming groups are variants of democratic organisation e In extreme programming groups some management decisions are devolved to group members Programmers work in pairs and take a collective responsibility for code that is developed Chief Programmer Teams Specialist pool Nucleus of chief programmer team Backup a programmer Outside Communication Consist of a kernel of specialists helped by others added to the project as required e The motivation behind their development is the wide difference in ability in different programmers Chief programmer team
234. s Organisational policy changes e Only realistic if an automatic translator is available 144 The Program Translation Process System to be System to be re engineered re engineered Automatically translate code Identify source code differences Design translator instructions Reverse Engineering e Analysing software with a view to understanding its design and specification e May be part of a re engineering process but may also be used to re specify a system for re implementation Manually translate code Builds a program data base and generates information from this Program understanding tools browsers cross reference generators etc may be used in this process The Reverse Engineering Process Program stucture diagrams amiotation e Reverse engineering often precedes re engineering but is sometimes worthwhile in its own right The design and specification of a system may be reverse engineered so that they can be an input to the requirements specification process for the system s replacement The design and specification may be reverse engineered to support program maintenance Program Structure Improvement e Maintenance tends to corrupt the structure of a program It becomes harder and harder to understand The program may be automatically restructured to remove unconditional branches Conditions may be simplified to make them more readable Condition Simplification Complex conditio
235. s Passive objects implemented as parallel processes with entry points corresponding to object operations If no 68 calls are made to it the object suspends itself and waits for further requests for service e Active objects implemented as parallel processes and the internal object state may be changed by the object itself and not simply by external calls Example An Active Transponder Object e A transponder object broadcasts an aircraft s position The object periodically updates the position by triangulation from satellites An Object oriented Design Process Define the context and modes of use of the system e Design the system architecture e Identify the principal system objects Develop design models static and dynamic e Specify object interfaces Weather System Description e A weather data collection system is required to generate weather maps on a regular basis using data collected from remote unattended weather stations and other data sources such as weather observers balloons and satellites Weather stations transmit their data to the area computer in response to a request from that machine e The area computer validates the collected data and integrates it with the data from different sources The integrated data is archived and using data from this archive and a digitised map database a set of local weather maps is created Maps may be printed for distribution on a special purpose map prin
236. s Commands are selected from a menu rather than Sen in a command language Pointing A pointing device such as a mouse is used for selecting choices from a menu or indicating items of interest ina window Graphics Graphical elements can be mixed with text on the same display GUI Advantages e They are easy to learn and use Users without experience can learn to use the system quickly e The user may switch quickly from one task to another and can interact with several different applications Information remains visible in its own window when attention is switched e Fast full screen interaction is possible with immediate access to anywhere on the screen User centred Design The aim of this chapter is to sensitise software engineers to key issues underlying the design rather than the implementation of user interfaces e User centred design is an approach to UI design where the needs of the user are paramount and where the user is involved in the design process e UI design always involves the development of prototype interfaces User Interface Design Process Analyse and understand user activities Produce paper based design prototype Design prototype Evaluate design with end users Prodig 2 Evaluate design dynamic design i bd with end users prototype Executable Implement final user rotot P ype interface UI Design Principles UI design must take account of the
237. s concerned with the practicalities of developing and delivering useful software Computer science theories are currently insufficient to act as a complete underpinning for software engineering What is The Difference Betw een Software Engineering and System Engineering System engineering is concerned with all aspects of computer based systems development including hardware software and process engineering Software engineering is part of this process System engineers are involved in system specification architec tural design integration and deployment What is a Software Process A set of activities whose goal is the development or evolution of software Generic activities in all software processes are e Specification what the system should do and its development constraints e Development production of the software system e Validation checking that the software is what the customer wants e Evolution changing the software in response to changing demands What is a Software Process M odel A simplified representation of a software process presented from a specific perspective Examples of process perspectives are e Workflow perspective sequence of activities e Dataflow perspective information flow e Role action perspective who does what Generic Process Models e Waterfall e Evolutionary development e Formal transformation e Integration from reusable components What are The Costs of Softw are Engi
238. s from a centralised architecture to client server architecture e Change drivers Hardware costs Servers are cheaper than mainframes User interface expectations Users expect graphical user interfaces Distributed access to systems Users wish to access the system from different geographically separated computers Distribution Factors Factor Description Business Returns onthe investmert of distributing alegacy system importance depend on it importance to the business and howlong t will remain mpatant If distribution provices more efficient suppat for stable business processes thenit is mare likely to bea cost effective evolution strategy System age The older the system the mae difficult it will be to modfy its architecture because previous changes will have degraded the structure of the system System structure The more modula the system the easier it will be to chang the architecture If the application logc the data management and the wer interface of the system are closely intertwined itwill be dfficult to separate functions for migration Hardware Application distribution may be necessary if there is procurement company policy toreplace expersive mainframe computers policies with cheaper servers Legacy System Structure e Ideally for distribution there should be a clear separation between the user interface the system services and the system data management e In practice these are usually interming
239. s may be synchronized Reactor Flux Monitoring Sensors each data flow is a sensor value A Sensor Processed identifier and flux level value Display Mutual Exclusion Producer processes collect data and add it to the buffer Consumer processes take data from the buffer and make elements available Producer and consumer processes must be mutually excluded from accessing the same element The buffer must stop producer processes adding information to a full buffer and consumer processes trying to take information from an empty buffer Java Implementation of a Ring Buffer 1 class CircularBuffer int bufsize SensorRecord store int numberOfEntries 0 int front 0 back 0 CircularBuffer int n bufsize n store new SensorRecord bufsize CircularBuffer synchronized void put SensorRecord rec throws InterruptedException if numberOfEntries bufsize wait store back new SensorRecord rec sensorld rec sensorVal back back 1 if back bufsize back 0 numberOfEntries numberOfEntries 1 notify put Java Implementation of a Ring Buffer 2 synchronized SensorRecord get throws InterruptedException SensorRecord result new SensorRecord 1 1 if numberOfEntries 0 wait result store front front front 1 if front bufsize front 0 numberOfEntries numberOfEntries 1 notify return resu
240. s provide a supporting environment for very able programmers to be responsible for most of the system development Problems e This chief programmer approach in different forms has undoubtedly been successful e However it suffers from a number of problems Talented designers and programmers are hard to find Without exception people in these roles the approach will fail Other group members may resent the chief programmer taking the credit for success so may deliberately undermine his her role High project risk as the project will fail if both the chief and deputy programmer are unavailable Organisational structures and grades may be unable to accom modate this type of group Choosing and Keeping People Choosing people to work on a project is a major managerial responsibility Appointment decisions are usually based on information provided by the candidate their resume or CV information gained at an interview recommendations from other people who know the candidate e Some companies use psychological or aptitude tests There is no agreement on whether or not these tests are actually useful 107 Staff Selection Factors Factor Explanation Application domain For a project to develop a successful system the experience developers must understand the application domain Platform experience May be significant if low level programming is involved Otherwise not usually a critical attribute Normally only si
241. s to developing a software design The design is usually documented as a set of graphical models Possible Models Dataflow model e Entity relation attribute model e Structural model e Object models Programming and Debugging Translating a design into a program and removing errors from that program compare with Clean room SE Programming is a personal activity a there is no generic programming process Programmers carry out some program testing to discover faults unit testing and remove faults in the debugging process The Debugging Process Locate Design Repair Re test error erior repair error program Software Verification amp Validation Verification and validation V amp V determines whether or not a system 1 conforms to its specification and 2 meets the needs of the customer Involves inspection review processes and machine based testing Testing involves executing system elements with test cases that are derived from specifications and or program logic Testing Stages Unit Module testing individual function procedures are tested unit module Integration testing Component testing functionally related units modules are tested together component Integration testing Sub system product testing sub systems or products are tested product sub system Integration testing System testing testing of the system as a whole including user acceptance test Software Evolution Software is
242. se Software engineers should not use their technical skills to misuse other people s computers Computer misuse ranges from relatively trivial game playing on an employer s machine say to extremely serious dissemination of viruses ACM IEEE Code of Ethics The professional societies in the US have cooperated to produce acode of ethical practice Members of these organisations sign up to the code of practice when they join The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers including practitioners educators managers supervisors and policy makers as well as trainees and students of the profes sion Code of Ethics Preamble Preamble e The short version of the code summarizes aspirations at a high level of the abstraction the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals Without the aspirations the details can become legalistic and tedious without the details the aspirations can become high sounding but empty together the aspirations and the details form a cohesive code e Software engineers shall commit themselves to making the analysis specification design development testing and maintenance of software a beneficial and respected profession In accordance with their commitment to the health safety and welfare of the public softwar
243. sed in the language of the application domain and may not be understood by software engineers e Implicitness domain experts may not communicate such requirements because they are so obvious to the experts User Requirements Shoulds e Should be understandable by system users who don t have detailed technical knowledge e Should only specify external system behaviour e Should be written using natural language forms and simple intuitive diagrams Some Potential Problems With Using Natural Language e Lack of clarity expressing requirements precisely is difficult without making the document wordy and difficult to read e Requirements confusion functions constraints goals and design info may not be clearly distinguished e Requirements amalgamation several different requirements may be lumped together Guidelines For Writing User Requirements e Adopt a standard format and use it for all requirements e Use language in a consistent way E g use shall for mandatory requirements should for desirable requirements e Use text highlighting to identify key parts of the requirement e Avoid the use of computer jargon 22 System Requirements e More detailed descriptions of user requirements e May serve as the basis for a contract e Starting point for system design amp implementation e May utilize different system models such as object or dataflow System Requirements And Design Information e I
244. ships using a viewpoint hierarchy diagram Activity For three of the viewpoints identified in the library cataloguing system suggest services which might be provided to that viewpoint data which the viewpoint might provide and events which control the delivery of these services Activity Using your own knowledge of how an ATM is used develop a set of use cases that could be used to derive the requirements for an ATM system 33 ONIYSANIDNA AYVMLAIOS ONIMSANIDON A AYVMLIOS Activity Discuss an example of a type of system where social and political factors might strongly influence the system require ments Explain why these factors are important in your example Activity Who should be involved in a requirements review Draw a process model showing how a requirements review might be organized Activity Why do tractability matrices become difficult to mange when there are many system requirements D esign a requirements structuring mechanism based on viewpoints which might help reduce the scale of this problem Activity When emergency changes have to be made to system software may have to be modified before changes to the requirements have been approved Suggest a model of a process for making these modifications which ensures that the requirements document and the system implementation do not become inconsistent 34 Activity Your company uses a standard analysis method which is normally applie
245. sign solutions Activity What are the major technical and non technical factors which hinder software reuse Form your own experience do you reuse much software If not why not Activity Explain why the savings in cost form reusing existing software is not simple proportional to the size of the components that are reused Activity Give four circumstances where you might recommend against software reuse 83 ONIYSANIDON A AYVMLIOS Activity Suggest possible requires and provides interfaces for the following components e A component implementing a bank account e A component implementing a language independent keyboard K eyboards in different countries have different key organizations and different character sets ONIMSANIDNA AYVMLIOS Activity What is the difference between an application framework and a COTS product as for as reuse is concerned Why is it some times easier to reuse a COTS product than an application framework Activity Why are patterns an effective form of design reuse What are the disadvantages to this approach to reuse Activity The reuse of software raises a number of copyright and intellectual property issues If a customer pays a software contractor to develop some system who has the right to reuse the developed code D oes the software contractor have the right to use that code as a basis for a generic component What payment mechanisms might be used to reimburse providers of re
246. stem provide the functions which best support the customer s needs Consistency Are there any requirements conflicts Completeness Are all functions required by the customer included e Realism Can the requirements be implemented given available budget and technology e Verifiability Can the requirements be tested Requirements Validation Techniques e Requirements reviews inspections systematic manual analysis of the requirements e Prototyping using an executable model of the system to check requirements e Test case generation developing tests for requirements to check testability e Automated consistency analysis checking the consistency of a structured requirements description Requirements Reviews Inspections Regular reviews should be held while the requirements definition is being formulated Both client and contractor staff should be involved in reviews Stakeholders e Reviews may be formal with completed documents or informal Good communications between developers customers and users can resolve problems at an early stage 31 Review Check list e Verifiability Is the requirement realistically testable Comprehensibility Is the requirement properly understood Traceability Is the origin of the requirement clearly stated e Adaptability Can the requirement be changed with minimum impact on other requirements Especially when change is anticipated Requirements
247. stems with well defined interfaces Specification of these interfaces allows for their independent development Interfaces are often defined as abstract data types or objects The algebraic approach is particularly well suited to the specification of such interfaces Sub system Interfaces Interface objects Sub system Sub s ystem A B Specification Components Introduction defines the sort type name and declares other specifications that are used Description informally describes the operations on the type Signature defines the syntax of the operations in the interface and their parameters Axioms defines the operation semantics by defining axioms which characterize behaviour Types of Operations Constructor operations operations which create modify entities of the type Inspection operations operations which evaluate entities of the type being specified Rule of thumb for defining axioms define an axiom which sets out what is always true for each inspection operation over each constructor Model based Specification Algebraic specification can be cumber some when object operations are not independent of object state i e previous operations e System State Model based specification exposes the system state and defines operations in terms of changes to that state e Z is a mature notation for model based specification It combines formal and informal descriptions and incorporates graphical
248. systems e Algebraic techniques are particularly suited to specifying interfaces of objects and abstract data types e In model based specification operations are defined in terms of changes to system state Activity Suggest why the architectural design of a system should precede the development of a formal specification Activity You have been given the task of selling formal specification techniques to a software development organization O utline how you would go about explaining the advantages of formal specifications to skeptical practicing software engineers Activity Explain why it is particularly important to define sub system interfaces in a precise way and why algebraic specification is particularly appropriate for sub system interface specification 52 Activity In the example of a controlled airspace sector the safety condition is that aircraft may not be within 300 m of height in the same sector Modify the specification shown in figure 9 8 to allow aircraft to occupy the same height in the sector so long as they are separated by at least 8km of horizontal difference You may ignore aircraft in adjacent sectors Hint You have to modify the constructor operations so that they include the aircraft position as well as its height You also have to define an operation that given two positions returns the separation between them Activity Bank teller machines rely on using information on the user s card giving
249. tRequired true PDL Disadvantages e PDL may not be sufficiently expressive to illustrate requirements in a concise an understandable way e Notation is only understandable to people with programming language knowledge e The specification may be taken as a design prescription rather than a model to facilitate requirements understanding Interface Specification e Used to specify operating interfaces with other systems Procedural interfaces D ata structures that are exchanged Data representations e Also used to specify functional behaviour e Formal notations are effective for interface specification e g pre and post conditions PDL Interface Description Example Interface and Operational Specifications of a Function interface PrintServer defines an abstract printer server requires interface Printer interface PrintDoc provides initialize print displayPrintQueue cancelPrintJob switchPrinter void initialize Printer p void print Printer p PrintDoc d void displayPrintQueue Printer p void cancelPrintJob Printer p PrintDoc d void switchPrinter Printer p1 Printer p2 PrintDoc d PrintServer Function Set BIG to the largest value in array A 1 N Interface Specification Pre condition N gt 1 Post condition there exists an i in 1 N such that BIG A i amp for every in 1 N BIG gt A j amp A is unchanged 23 Operational Specification if N e 1
250. ted query language e Data dictionary Report definition and generation tools e Forms definition tools e Import export translators e Code generation tools Key Points e A model is an abstract system view Complementary types of model provide different system information Context models show the position of a system in its environment with other systems and processes Data flow models may be used to model the data processing in a system e State machine models model the system s behaviour in response to internal or external events e Semantic data models describe the logical structure of data which is imported to or exported by the systems e Object models describe logical system entities their classification and aggregation e Object models describe the logical system entities and their classification and aggregation e CASE workbenches support the development of system models Activity Draw acontext model for a patient information system in a hospital You may make any reasonable assumptions about the other hospital systems which are available but your model must include a patient admissions system and an image storage system for X rays 40 Activity Based on your experience with a bank ATM draw a data flow diagram modeling the data processing involved when a customer withdraws cash form the machine Activity Model the data processing which might take place in an electronic mail system You should mod
251. tem level activities such as integration and documentation Estimation Methods Each method has strengths and weaknesses e Estimation should be based on several methods e If these do not return approximately the same result there is insufficient information available e Some action should be taken to find out more in order to make more accurate estimates e Pricing to win is sometimes the only applicable method Experience based Estimates Estimating is primarily experience based e However new methods and technologies may make estimating based on experience inaccurate Object oriented rather than function oriented development Client server systems rather than mainframe systems Off the shelf components Component based software engineering CASE tools and program generators Pricing to Win This approach may seem unethical and unbusinesslike However when detailed information is lacking it may be the only appropriate strategy The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost e A detailed specification may be negotiated or an evolutionary approach used for system development Algorithmic Cost Modelling e Cost is estimated as a mathematical function of product project and process attributes whose values are estimated by project managers Effort A SizeB M 114 A is an organisation dependent constant B reflects the dispro portionate effort f
252. ter or may be displayed in a number of different formats e A weather station is a package of software controlled instruments which collects data performs some data processing and transmits this data for further processing The instruments include air and ground thermometers an anemometer a wind vane a barometer and a rain gauge Data is collected every five minutes e When a command is issued to transmit the weather data the weather station processes and summarises the collected data The summarised data is transmitted to the mapping computer when a request is received 1 Define system context and modes of use e Goal develop an understanding of the relationships between the software being designed and its external environment e System context a static model that describes other systems in the environment e The context of the weather station is illustrated below using UML packages Context of Weather Station subsystem Data collection subsystem Data display a User Map interface display Map Subsystem Data archiving E storage e Modes of system use a dynamic model that describes how the system will interact with its environment subsystem Data processing Data Data checking integration e Modes of weather station use are illustrated below using a UML use case model Use cases for the Weather Station Use case Description System W
253. termines product quality For small projects the capabilities of the developers is the main determinant 127 The development technology is particularly significant for small projects e In all cases if an unrealistic schedule is imposed then product quality will suffer Process Analysis and Modelling e Process analysis The study of existing processes to understand the relationships between parts of the process and to compare them with other processes e Process modelling The documentation of a process which records the tasks the roles and the entities used Process models may be presented from different perspectives e Study an existing process to understand its activities e Produce an abstract model of the process You should normally represent this graphically Several different views e g activities deliverables etc may be required e Analyse the model to discover process problems Involves discussing activities with stakeholders Process Analysis Techniques e Published process models and process standards It is always best to start process analysis with an existing model People then may extend and change this e Questionnaires and interviews Must be carefully designed Participants may tell you what they think you want to hear Ethnographic analysis Involves assimilating process knowledge by observation Elements of a Process Model Process model element Description Activity An acti
254. then do BIG A 1 fori 2 to N do if A i gt BIG then BIG A i end if end for end if The Requirements Document SRS e The official statement of what is required of the system developers Should include both user and system requirements NOT a design document As much as possible it should set out WHAT the system should do rather than HOW it should do it Users of a Requirements Document Specify the requirements and read them to check that they meet their needs They specify changes to the requirements System customers Use the requirements document to plan a bid for the system and to plan the system development process Managers Use the requirements to understand whatsystem is to be developed System engineers System test engineers it Use the requirements to develop validation tests for the system Use the requirements to help System maintenance understand the system and engineers the relationships betw een its parts Requirements Document Requirements e Specify external system behaviour e Specify implementation constraints e Easy to change 1 Serve as reference tool for maintenance Record forethought about the life cycle of the system i e predict changes e Characterise responses to unexpected events IEEE Requirements Standard e Introduction e General description e Specific requirements Appendices Index e This is a generic structure that must be instantiated
255. tion of compatible tools is relatively easy Repository Model Disadvantages e Sub systems must agree on a single repository data model This is inevitably a compromise e Data model evolution is difficult and expensive No provision for sub system specific data management requirements related to backup access control and recovery e May be difficult to distribute efficiently over a number of machines due to problems with data redundancy and inconsistency The Client server M odel Distributed system model which shows how data and processing are distributed across a range of processors e Major components are A set of stand alone servers which provide specific services such as printing file management etc A set of clients which call on these services A network which allows clients to access these services Film and Picture Library Wide bandwidth network Client server Model Advantages Supports distributed computing Underlying network makes distribution of data straightforward No shared data model so servers may organize data to optimise their performance Distinction between servers and clients may allow use of cheaper hardware e Relatively easy to expand or upgrade system 55 Client server Model Disadvantages Relatively complex architecture problem determination can be difficult No shared data model so data integration may be problematic Redundant data management
256. to object oriented Activity Explain why it is impossible to recover a system specification be automatically analyzing system source code 147 ONIMAANIDNA AYVMLIOS ONIMSAANIDN A AYVMLIOS Activity Using examples describe the problems with data degradation which may have to be tackled during the process of data cleanup Activity The year 2000 problem where dates were represented as two digits posed a major program maintenance problem for many organizations What were the implications of this problem for data re engineering Activity A company routinely places contractual conditions on freelance working on re engineering their applications which prevents them from taking on contracts with similar companies The reason for this is that re engineering inevitably reveals business information Is this a reasonable position for a company to take given that they have no obligations to contractors after their contract has finished 148 LESSON 39 AND 40 CONFIGURATION MANAGEMENT Managing The Products of System Change Objectives To explain the importance of software configuration management CM To describe key CM activities namely CM planning change management version management and system building To discuss the use of CASE tools to support configuration management processes Topics Covered Configuration management planning e Change management e Version and release management e System build
257. tract representation of a process It presents a description of a process from some particular perspective Models should be as simple as possible but no Simple A Einstein Generic Softw are Process M odels The Waterfall Model separate and distinct phases of specifica tion and development Evolutionary Development specification and development are interleaved Formal Systems Development a mathematical system model is formally transformed to an implementation Reuse Based D evelopment the system is assembled from existing components Waterfall Model Requirements definition System and software design Implementation and unit testing Integration and system testing maintenance Waterfall Model Problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements Thus this model is only appropriate when the requirements are well understood In general the drawback of the waterfall model is the difficulty of accommodating change after the process is underway Evolutionary Development Exploratory Development objective is to work with customers and to evolve a final system from an initial outline specification D evelopment starts with well understood parts of system Throwaway Prototyping objective is to understand the system requirements Prototyping focuses on poorly understood requirements e Also known as exploratory
258. ts associated documentation e Code designs specifications test plans standards etc can all be reviewed Software or documents may be signed off at a review which signifies that progress to the next development stage has been approved by management The Review Process Select review team Complete review forms Arrange place and time Holdreview Distribute documents Review Functions e Quality function They are part of the general quality management process e Project management function They provide information for project managers Training and communication function product knowledge is passed between development team members 122 Quality Reviews e Objective is the discovery of system defects and inconsistencies e Any documents produced in the process may be reviewed e Review teams should be relatively small and reviews should be fairly short e Review should be recorded and records maintained Review Results Comments made during the review should be classified No action No change to the software or documentation is required Refer for repair D esigner or programmer should correct an identified fault Reconsider overall design The problem identified in the review impacts other parts of the design Some overall judgement must be made about the most cost effective way of solving the problem Requirements and specification errors may have
259. ture hidden e Complex dependencies between parts of the program can cause maintainability problems User Interface Prototyping e It is impossible to pre specify the look and feel of a user interface in an effective way Prototyping is essential e UI development consumes an increasing part of overall system development costs e User interface generators may be used to draw the interface and simulate its functionality with components associated with interface entities Web interfaces may be prototyped using a web site editor Key Points e A prototype can be used to give end users a concrete impression of the system s capabilities Prototyping is becoming increasingly used for system development where rapid development is essential Throw away prototyping is used to understand the system requirements e In evolutionary prototyping the system is developed by evolving an initial version to the final version e Rapid development of prototypes is essential This may require leaving out functionality or relaxing non functional constraints Prototyping techniques include the use of very high level languages database programming and prototype construction from reusable components Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre specified Users must be involved in prototype evaluation Activity You have been asked to investigate the feasibility o
260. turns results to requesters e A set of general object services of use to many distributed applications e A set of common components built on top of these services Task forces are currently defining these CORBA Objects Objects that provide services have ID L skeletons that link their interface to an implementation e Calling objects have ID L stubs for every object being called Objects do not need to know the location or implementation details of other objects Object Request Broker ORB e The ORB handles object communications It knows of all objects in the system and their interfaces e The calling object binds an IDL stub that defines the interface of the called object Calling this stub results in calls to the ORB which then calls the required object through a published IDL skeleton that links the interface to the service implementation ORB based Object Communications Object Request Broker Inter ORB Communications e ORBs handle communications between objects executing on the same machine e Inter ORB communications are used for distributed object calls CORBA supports ORB to ORB communication by providing all O RBs access to all ID L interface definitions and by implementing the OMG s standard Generic Inter O RB Protocol GIO P Inter ORB Communications Object Request Broker Object Request Broker Network Examples of General CORBA Services Naming and trading services
261. ule Re negotiate project constraints and deliverables if problems arise then Initiate technical review and possible revision end if end loop Project Plan Document Structure e Introduction goals constraints etc e Project organisation e Risk analysis e Hardware and software resource requirements e Work breakdown e Project schedule e Monitoring and reporting mechanisms Activity Organization e Activities in a project should be associated with tangible outputs for management to judge progress i e to provide process visibility e Milestones are the unequivocal end points of process activities e Deliverables are project results delivered to customers There are also internal deliverables e The waterfall model allows for the straightforward definition of milestones a deliverable oriented model e Deliverables are always milestones but milestones are not necessarily deliverables Milestones in The Re Process ACTIVITIES MILESTONES Project Scheduling e Split project into tasks and estimate time and resources required to complete each e Tasks should not be too small or too large they should last on the order of weeks for projects lasting months e Organize as concurrent activities to make optimal use of workforce e Minimize task dependencies to avoid potential delays e Dependent on project managers intuition and experience The Project Scheduling Process Soliwae Activity cha
262. ure e Software re engineering No new functionality is added to the system but it is restruc tured and reorganised to facilitate future changes These strategies may be applied separately or together Program Evolution Dynamics e Program evolution dynamics is the study of the processes of system change e After major empirical study Lehman and Belady proposed that there were a number of laws which applied to all systems as they evolved There are sensible observations rather than laws They are applicable to large systems developed by large organisations Perhaps less applicable in other cases Lehman s laws Law Description Continuing change A program that is used in a real world environment necessarily must change or become progressively less useful in that environment Increasing complexity As an evolving program changes its structure tends to become more complex Extra resources must be devoted to preserving and simplifying the structure Program evolution is a self regulating process System attributes such as size time between releases and the number of reported errors are approximately invariant for each system release Over a program s lifetime its rate of development is approximately constant and independent of the resources devoted to system development Conservation of Over the lifetime of a system the incremental change familiarity in each release is approximately constant Large
263. usable components D iscuss these issues and other ethical issues associated with the reuse of software 84 LESSON 24 AND 25 USER INTERFACE DESIGN Designing Effective Interfaces for Softw are Systems Objectives e To suggest some general design principles for user interface design To explain different interaction styles To introduce styles of information presentation To describe the user support which should be built in to user interfaces To introduce usability attributes and system approaches to system evaluation Topics Covered e User interface design principles e User interaction e Information presentation e User support e Interface evaluation The User Interface e System users often judge a system by its interface rather than its functionality e A poorly designed interface can cause a user to make catastrophic errors Poor user interface design is the reason why so many software systems are never used Graphical User Interfaces Most users of business systems interact with these systems through graphical interfaces although in some cases legacy text based interfaces are still used GUI Characteristics Characteristic Description Windows Multiple windows allow different information to be displayed simultaneously on the user s screen Icons Icons different types of information On some systems icons represent files on others icons represent rocesses Menu
264. validation rules Data written by tules one program may be rejected by another This is a particular problem for archival data which may not have been updated in line with changes to data validation rules Inconsistent units Inconsistent Programs assume some meaning in the way items are represented For representation example some programs may assume that upper case text means an semantics address Programs may use different conventions and may therefore reject data which is semantically valid Some programs reject negative values for entities which must always be positive Others however may accept these as negative values or fail to recognise them as negative and convert them to a positive value Inconsistent handling of negative values Data Migration Becomes describes Database Program 1 management opia aid system physical data models Data naming problems Names may be hard to understand The same data may have different names in different programs e Field length problems The same item may be assigned different lengths in different programs Record organisation problems Records representing the same entity may be organised differ ently in different programs e Hard coded literals e No data dictionary Data Conversion Data re engineering may involve changing the data structure organisation without changing the data values e Data value conversion is very ex
265. ve of the estimation technique used Suggest four ways in which the risk in a cost estimate can be reduced 117 ONIMAANIDON A AYVMLIOS Activity Give three reasons why algorithmic cost estimates prepared in different organizations are not directly comparable Activity Explain how the algorithmic approach to cost estimation may be used by project mangers for option analysis Suggest a situation where mangers may choose an approach that is not based on the lowest project cost Activity Implement the COCO MO model using a spreadsheet such as Microsoft excel Details of the model can be downloaded form the COCO MO2 web site Activity Some very large software projects involve the writing of millions of lines of code Suggest how useful the cost estima tion models are likely to be for such systems Why might the assumptions on which they are based be invalid for very large software system 118 Activity Is it ethical for a company to quote a low price for a software contract knowing that the requirements are ambiguous and that they can charge a high price for subsequent changes requested by the customer Activity Should measured productivity be used by managers during the staff appraisal process What safeguards are necessary to ensure that quality is not affected by this Notes 119 ONIMAANIDN A AYVMLIOS LESSON 33 AND 34 QUALITY MANAGEMENT Managing the Quality of the Software Process and Products Obj
266. ve to be rewritten and cleaned up to reflect the program changes Data migration In this case data is moved into the control of a modern database management system The data may be stored in separate files or may be managed by an older type of DBMS Data Problems e End users want data on their desktop machines rather than in a file system They need to be able to download this data from a DBMS e Systems may have to process much more data than was originally intended by their designers Redundant data may be stored in different formats in different places in the system Data Value Inconsistencies Data inconsistency Description Inconsistent default Different programs assign different default values to the same logical data values items This causes problems for programs other than those that created the data The problem is compounded when missing values are assigned a default value that is valid The missing data cannot then be discovered The same information is represented in different units in different programs For example in the US or the UK weight data may be represented in pounds in older programs but in kilograms in more recent systems A major problem of this type has arisen in Europe with the introduction of a single European currency Legacy systems have been written to deal with national currency units and data has to be converted to euros Inconsistent validation Different programs apply different data
267. vely used in data processing systems Not really suitable for interactive systems input data streams versus events Invoice Processing System Domain specific Architectures e Architectural models which are specific to some application domain e Two types of domain specific models 1 Generic models encapsulate the traditional time tested characteristics of real systems 2 Reference models are more abstract and describe a larger class of systems They provide a means of comparing different systems in a domain e Generic models are usually bottom up models Reference models are top down models Generic Models e The compiler model is a well known example Based on the thousands written it is now generally agreed that the standard components of a compiler are Lexical analyser Symbol table Syntax analyser Syntax tree Semantic analyser Code generator Compiler Model Lexical Syn tactic Semantic Code analysis analy sis analysis generation Sequential function model batch processing oriented 57 ONIYSANIDONA AYVMLAIOS Language Processing System Abstract Grammar syntax tree definition Symbol Output table definition Reposi ory Repository based mode Reference Architectures Reference models are derived from a study of the application domain rather than from existing systems May be used as a basis for system implementation or to compare different systems It acts as a standard agai
268. vity Write a short set of guidelines for designers of user guidance systems 91 ONIMSANIDN A AYVMLIOS ONIMAANIDON A JAVMI OS Notes Activity 7 Design a questionnaire to gather information about the user interface f some tool such as a word processor with which you are familiar If possible distribute this questionnaire to a number of users and try to evaluate the results What do these tell you about the user interface design Activity 8 What ethical issues might user interface designers face when trying to reconcile the needs of end users of a system with the needs of the organization which is paying for the system to be developed 92 LESSON 26 VERIFICATION AND VALIDATION Objectives e To introduce software verification and validation and to discuss the distinction between them To describe the program inspection review process and its roleinV amp V To describe the Clean room software development process Topics Covered e Software inspections reviews e Cleanroom software development Verification Vs Validation e Verification Are we building the product right The software should conform to its specification Validation Are we building the right product The software should do what the user really needs wants Static and Dynamic V amp V Software inspections reviews analyse static system representations such as requirements design source code etc static
269. vity has a clearly de fined obj ective entry and exit represented by a round condition s Examples of activities are preparing a set of test edged rectangle with no data to test a modul e coding a function or a modul e proo f drop shadow reading a document etc Generally an activity is atomic i e itis the respon sibili ty of on e person or group It i s not decomposed into sub activiti es Process A process is a set of activities which have some coherence represented by a round and whose objective is generally agreed within an edged rectangle with drop organisation Ex amples of processes are requirements shadow analysis architectural design test pl anning e tc Deliverable A deliverable is a tangible output of an activity which is represented by a rectangle predicted in a project plan with drop shadow Condition A condition i s either a pre condition which must hold be fore represented by a a process or activity can start or a post condit ion which hold s parallelogram after a process or activity h as finished Role A role is a bounded area of responsib ility Ex amples of roles represented by a circle might b e configu ration manager test engine er software with drop shadow designer etc One person may have several dif ferent roles and a singl e role may be associated with several diff erent people Exception not shown in examples here but may be represented as a doubl e edged box An
270. w methods Controller methods Model queries and updates Model edits Model state Model methods Information Presentation e Static information Initialised at the beginning of a session It does not change during the session May be either numeric or textual e Dynamic information Changes during a session and the changes must be communi cated to the system user May be either numeric or textual Information Display Factors e Is the user interested in precise information or data relationships How quickly do information values change Must the change be indicated immediately e Must the user take some action in response to a change e Is there a direct manipulation interface e Is the information textual or numeric Are relative values important Alternative Information Presentations Jan Feb Mar Apnl May June 2842 2851 3164 2789 1273 2835 4000 3000 2000 1000 0 Jan Feb Mar April May June Analogue Vs Digital Presentation Digital presentation Compact takes up little screen space Precise values can be communicated e Analogue presentation Easier to get an at a glance impression of a value Possible to show relative values Easier to see exceptional data values Dynamic Information Display OP 0 10 20 kk Dial with needle Pie chart Thermometer Horizontal bar Displaying Relative Values Pressure nperare 10 20 30 400 B83 SO 6 Sl ee y
271. ware project tracking and oversight Software project planning Requirements management Initial SEI Model Problems e It focuses on project management rather than product development e It ignores the use of technologies such as rapid prototyping e It does not incorporate risk analysis as a key process area e It does not define its domain of applicability The CMM and ISO 9000 e There is aclear correlation between the key processes in the CMM and the quality management processes in ISO 9000 e The CMM is more detailed and prescriptive and includes a framework for improvement e Organisations rated as level 2 in the CMM are likely to be ISO 9000 compliant Capability Assessment e An important role of the SEI is to use the CMM to assess the capabilities of contractors bidding for US government defence contracts The model is intended to represent organisational capability not the practices used in particular projects Within the same organisation there are often wide variations in processes used 129 ONIMSANIDONA AYVMLAIOS e Capability assessment is questionnaire based The Capability Assessment Process Select projects Distribute for assessment questionnaires Identify issues for discussion Present assessment i Process Classification e Informal No detailed process model D evelopment team chose their own way of working e Managed D efined process model which drives the development proc
272. ws fast response but is complex to program and difficult to verify Why Interrupt driven Control Interrupts Interrupt vector Modular Decomposition A K A High level Design e Sub systems are decomposed into lower level elements e Two models are considered An object model where the system is decom posed into interacting objects object oriented design A data flow model where the system is decomposed into functional modules which transform inputs into outputs function oriented design Object Models e Structure the system into a set of loosely coupled objects with well defined interfaces e Object oriented decomposition is concemed with identifying object classes their attributes and operations e When implemented objects are created from these classes and some control model is used to coordinate object operations Invoice Processing System Customer customer invoice name date address credit period amount customer Invoice invoice date amount customer issue sendR eminder acceptPayment sendR eceipt imoice date amount customer Data flow Models e Functional transformations process inputs to produce outputs e Sometimes referred to as a pipe and filter model after terminology used in UNIX Variants of this approach have a long history in software design e When transformations are sequential this is a batch sequential model Which is extensi
273. y by a circuit monitor When received the system must switch to backup power within 50ms e Intruder alarm Stimulus generated by system sensors Response is to call the police switch on building lights and the audible alarm Timing Requirements Stimulus Resp onse Timing requirements Power fail interrupt The switch to backup power must be completed within a deadline of 50 ms Door alarm Eac h door alarm sh ould be polled twice per second Window alarm Eac h window alarm sh ould be polled twice per second Movement detec tor Eac h mo ve ment detect or s hould be polled twice per second Theaudible alarm should be switched on within 1 2 second of an alarm being raised by asensor The lights sh ould be s witched on within 1 2 second of an alarm b eing raised by a sensor Audible alarm Lights sw itch Comm unica tions The ca ll to the police should be started within 2 seconds of an alarm being raised by a sensor Voice sy nthesiser A synthesised message should be available within 4s econds of an alarm be ingraised by a sensor Process Architecture 400Hz 60Hz 100Hz Movement Door sensor Window sensor detector process process process Detector status Sensor status S Alarm system Building monitor Communication process process Room number en sor status Power failure interru pt Building monitor Power switch process system process Alert m
274. yboard so typing ability is required Command Languages Often preferred by experienced users because they allow for faster interaction with the system e Not suitable for casual or inexperienced users e May be provided as an alternative to menu commands keyboard shortcuts In some cases a command language interface and a menu based interface are supported at the same time Natural Language Interfaces e The user types a command in a natural language G enereally the vocabulary is limited and these systems are confined to specific application domains e g timetable enquiries NL processing technology is now good enough to make these interfaces effective for casual users but experienced users find that they require too much typing Multiple User Interfaces Command lan guage interface Graphical user interface Command lan guage interpreter Operating system Information Presentation e Information presentation is concerned with presenting system information to system users GUI manager The information may be presented directly e g text in a word processor or may be transformed in some way for presentation e g in some graphical form The Model View Controller approach is a way of supporting multiple presentations of data Information to Presentation be displayed software Model view controller View state view modification Controller state messages User inputs Vie

Software Engineering

Contents

Download Pdf Manuals

Related Search

Related Contents