Subject Name SOFTWARE ENGINEERING Subject Code 10 IS

Subject Name: SOFTWARE ENGINEERING Subject Code: 10 IS 51 Prepared By: HARKIRANPREET, ALPNA Department: ISE Date: 25 September, 2014 25/9/2014

UNIT 4 PROJECT MANAGEMENT 25/9/2014

CONTENTS • Management activities • Project planning • Project scheduling • Risk management 25/9/2014

SOFTWARE PROJECT MANAGEMENT • It is Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software. • Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software. 25/9/2014

SOFTWARE MANAGEMENT DISTINCTIONS • The product is intangible. • The product is uniquely flexible. • Software engineering is not recognized as engineering discipline with the sane status mechanical, electrical engineering, etc. • The software standardised. development process • Many software projects are 'one-off' projects. 25/9/2014 is an as not

MANAGEMENT ACTIVITIES • Proposal writing. • Project planning and scheduling. • Project costing. • Project monitoring and reviews. • Personnel selection and evaluation. • Report writing and presentations. 25/9/2014

MANAGEMENT COMMONALITIES • These activities management. are not peculiar to software • Many techniques of engineering project management are equally applicable to software project management. • Technically complex to suffer from the systems. 25/9/2014 engineering systems tend same problems as software

PROJECT STAFFING • May not be possible to appoint the ideal people to work on a project. • Project budget may not allow for the use of highly-paid staff. • Staff with the appropriate experience may not be available. • An organisation may wish to develop employee skills on a software project. • Managers have to work within these constraints especially when there are shortages of trained staff. 25/9/2014

PROJECT PLANNING • Probably the most time-consuming project management activity. • Continuous activity to system delivery. from initial concept through • Plans must be regularly revised as new information becomes available. • Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget. 25/9/2014

TYPES OF PROJECT PLAN 25/9/2014

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 cancelled loop Draw up project schedule Initiate activities according to schedule Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end if end loop 25/9/2014

PROJECT PLAN STRUCTURE I. Introduction. II. Project organisation. III. Risk analysis. IV. Hardware and software resource requirements. V. Work breakdown. VI. Project schedule. VII. Monitoring and reporting mechanisms. 25/9/2014

ACTIVITY ORGANIZATION I. Activities in a project should be organised to produce tangible outputs for management to judge progress. II. Milestones are the end-point of a process activity. III. Deliverables are project results delivered to customers. IV. The waterfall process allows for the straightforward definition of progress milestones. 25/9/2014

MILESTONES IN THE RE PROCESS • 25/9/2014

PROJECT SCHEDULING • Split project into tasks and estimate time and resources required to complete each task. • Organize tasks use of workforce. concurrently to make optimal • Minimize task dependencies to avoid delays caused by one task waiting for another to complete. • Dependent on project managers intuition and experience. 25/9/2014

THE PROJECT SCHEDULING PROCESS 25/9/2014

SCHEDULING PROBLEMS • Estimating the difficulty of problems and hence the cost of developing a solution is hard. • Productivity is not proportional to the number of people working on a task. • Adding people to a late project makes it later because of communication overheads. • The unexpected always happens. Always allow contingency in planning. 25/9/2014

BAR CHARTS AND ACTIVITY NETWORKS • Graphical notations used to illustrate the project schedule. • Show project breakdown into tasks. • Tasks should not be too small. They should take about a week or two. • Activity charts show task dependencies and the critical path. • Bar charts show schedule against calendar time. 25/9/2014

TASK DURATIONS AND DEPENDENCIES 25/9/2014

ACTIVITY NETWORK 25/9/2014

ACTIVITY TIMELINE 25/9/2014

STAFF ALLOCATION 25/9/2014

RISK MANAGEMENT • Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. • 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. 25/9/2014

SOFTWARE RISKS 25/9/2014

THE RISK MANAGEMENT PROCESS • Risk identification • Identify project, product and business risks; • Risk analysis • Assess the likelihood and consequences of these risks; • Risk planning • Draw up plans to avoid or minimise the effects of the risk; • Risk monitoring • Monitor the risks throughout the project; 25/9/2014

THE RISK MANAGEMENT PROCESS 25/9/2014

RISK IDENTIFICATION • Technology risks. • People risks. • Organisational risks. • Requirements risks. • Estimation risks. 25/9/2014

RISKS AND RISK TYPES 25/9/2014

RISK ANALYSIS • Assess probability and seriousness of each risk. • Probability may be very low, moderate, high or very high. • Risk effects might be catastrophic, serious, tolerable or insignificant. 25/9/2014

RISK ANALYSIS (I) 25/9/2014

RISK ANALYSIS (II) 25/9/2014

RISK PLANNING • 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 will be reduced; • Contingency plans – If the risk arises, contingency plans are plans to deal with that risk; 25/9/2014

RISK MANAGEMENT STRATEGIES (I) 25/9/2014

RISK MANAGEMENT STRATEGIES (II) 25/9/2014

RISK MONITORING • Assess each identified risks regularly to decide whether or not it is becoming less or more probable. • Also assess whether the effects of the risk have changed. • Each key risk should be discussed at management progress meetings. 25/9/2014

RISK INDICATORS 25/9/2014

SYSTEM MODELS 25/9/2014

CONTENTS • Context models • Behavioural models • Data models • Object models • CASE workbenches 25/9/2014

SYSTEM MODELLING • 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 environment; – Behavioural perspective showing the behaviour of the system; – Structural perspective showing the system or data architecture. 25/9/2014

MODEL TYPES • Data processing model showing how the data is processed at different stages. • Composition model showing how entities are composed of other entities. • Architectural model showing principal sub-systems. • Classification model showing how entities have common characteristics. • Stimulus/response model showing the system’s reaction to events. 25/9/2014

CONTEXT MODELS • Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. • Social and organisational concerns may affect the decision on where to position system boundaries. • Architectural models show the system and its relationship with other systems. 25/9/2014

THE CONTEXT OF AN ATM SYSTEM 25/9/2014

PROCESS MODELS • 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 one process to another. 25/9/2014

EQUIPMENT PROCUREMENT PROCESS 25/9/2014

BEHAVIOURAL MODELS • Behavioural models are used to describe the overall behaviour of a system. • Two types of behavioural model are: – Data processing models that show data is processed as it moves through the system; – State machine models that show the systems response to events. • These models show different perspectives so both of them are required to describe the system’s behaviour. 25/9/2014

DATA-PROCESSING MODELS • Data flow diagrams (DFDs) may be used to model the system’s data processing. • These show the processing steps as data flows through a system. • DFDs are an intrinsic part of many analysis methods. • Simple and intuitive notation that customers can understand. • Show end-to-end processing of data. 25/9/2014

ORDER PROCESSING DFD 25/9/2014

DATA FLOW DIAGRAMS • DFDs model the system from a functional perspective. • 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 DFDs model the system from a functional perspective. 25/9/2014

INSULIN PUMP DFD 25/9/2014

STATE MACHINE MODELS • These model the behaviour of the system in response to external and internal events. • They show the system’s responses to stimuli so are often used for modelling real-time systems. • 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. • State charts are an integral part of the UML and are used to represent state machine models. 25/9/2014

STATE CHARTS • Allow the decomposition of a model into sub-models (see following slide). • A brief description of the actions is included following the ‘do’ in each state. • Can be complemented by tables describing the states and the stimuli. 25/9/2014

MICROWAVE OVEN MODEL 25/9/2014

MICROWAVE OVEN STATE DESCRIPTION 25/9/2014

MICROWAVE OVEN STIMULI 25/9/2014

MICROWAVE OVEN OPERATION 25/9/2014

SEMANTIC DATA MODELS • Used to describe the logical structure of data processed by the system. • An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes • 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. 25/9/2014

LIBRARY SEMANTIC MODEL 25/9/2014

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. • Advantages – Support name management and avoid duplication; – Store of organisational knowledge linking analysis, design and implementation; • Many CASE workbenches support data dictionaries. 25/9/2014

DATA DICTIONARY ENTRIES 25/9/2014

OBJECT MODELS • Object models describe the system in terms of object classes and their associations. • 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; – Aggregation models; – Interaction models. 25/9/2014

OBJECT MODELS • Natural ways of reflecting the real-world entities manipulated by the system • More abstract entities are more difficult to model using this approach • Object class identification is recognised as a difficult process requiring a deep understanding of the application domain • Object classes reflecting domain entities are reusable across systems 25/9/2014

INHERITANCE MODELS • Organise the domain object classes into a hierarchy. • 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. • Class hierarchy design can be a difficult process if duplication in different branches is to be avoided. 25/9/2014

OBJECT MODELS AND THE UML • The UML is a standard representation devised by the developers of widely used object-oriented analysis and design methods. • It has become an effective standard for object-oriented modelling. • 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. 25/9/2014

LIBRARY CLASS HIERARCHY 25/9/2014

USER CLASS HIERARCHY 25/9/2014

MULTIPLE INHERITANCE • 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. • This can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. • Multiple inheritance makes class hierarchy reorganisation more complex. 25/9/2014

MULTIPLE INHERITANCE 25/9/2014

OBJECT AGGREGATION • An aggregation model shows how classes that are collections are composed of other classes. • Aggregation models are similar to the part-of relationship in semantic data models. 25/9/2014

OBJECT AGGREGATION 25/9/2014

OBJECT BEHAVIOUR MODELLING • A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case. • Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects. 25/9/2014

ISSUE OF ELECTRONIC ITEMS 25/9/2014

STRUCTURED METHODS • Structured methods incorporate system modelling as an inherent part of the method. • Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models. • CASE tools support system modelling as part of a structured method. 25/9/2014

METHOD WEAKNESSES • They do not model non-functional system requirements. • They do not usually include information about whether a method is appropriate for a given problem. • The may produce too much documentation. • The system models are sometimes too detailed and difficult for users to understand. 25/9/2014

CASE WORKBENCHES • A coherent set of tools that is designed to support related software process activities such as analysis, design or testing. • 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. 25/9/2014

AN ANALYSIS AND DESIGN WORKBENCH 25/9/2014

ANALYSIS WORKBENCH COMPONENTS • Diagram editors • Model analysis and checking tools • Repository and associated query language • Data dictionary • Report definition and generation tools • Forms definition tools • Import/export translators • Code generation tools 25/9/2014

Thank you…. . 25/9/2014

25/9/2014