AP
Uploaded byarvind pandey
PDF, PPTX9,552 views

Unit 4- Software Engineering System Model Notes

This document discusses system modeling techniques used in software engineering. It covers context models, behavioral models, data models, object models, and CASE workbenches. Different types of models present the system from external, behavioral, and structural perspectives. Common model types include data processing, composition, architectural, and classification models. The document provides examples of context models, state machine models, data flow diagrams, and object models. It also discusses semantic data models, object behavior modeling with sequence diagrams, and components of analysis and design workbenches.

Embed presentation

Download as PDF, PPTX
Unit-4 System modelsSystem models
Topics covered Context models Behavioural modelsBehavioural models Data models Object models CASE workbenches
System modelling System modelling helps the analystanalyst to understand the functionality of the system and modelsmodels are usedy y to communicatecommunicate with customerscustomers.. Different models present the system from differentDifferent models present the system from different perspectives •• ExternalExternal perspectiveperspective showing the system’s context or environment; Beha io ralBeha io ral perspecti eperspecti e sho ing the beha io r of the s stem•• BehaviouralBehavioural perspectiveperspective showing the behaviour of the system; •• StructuralStructural perspectiveperspective showing the system or data architecture.architecture.
Model types DataData processingprocessing modelmodel showing how the datadata isis processedprocessed at different stages. CompositionComposition modelmodel showing how entitiesentities areare composedcomposed of other entitiescomposedcomposed of other entities. ArchitecturalArchitectural modelmodel showing principal sub-systems. ClassificationClassification modelmodel showing how entitiesentities havehave commoncommon characteristicscharacteristics. Stimulus/responseStimulus/response model/Statemodel/State showing the system’s reaction to eventssystem s reaction to events.
Context models-External perspectiveExternal perspective Context models are used to illustrate the operationaloperational contextcontext of a system - they show whatpp y y lies outsideoutside thethe systemsystem boundariesboundaries.
The context of an ATM system Security system Account da tabase Branch accounting system Auto-teller system Branch M i t Usage database Branch counter system Maintenance system
Behavioural models Behavioural models are used to describe the overall behaviour of a system. Two types of behavioural model are: •• DataData processingprocessing modelsmodels that show how data•• DataData processingprocessing modelsmodels that show how data is processed as it moves through the system; •• StateState machinemachine modelsmodels that show the systems response to events.
Process models Data flow models may be used to show the processes and the flowflow ofof informationinformation fromfrom oneonep processprocess toto anotheranother..
Data-processing models Data flow diagrams (DFDs) may be used to model the system’s data processing.y p g These show the processing steps as data flows through a systemthrough a system. DFDs are an intrinsic part of many analysis methods. Simple and intuitive notation that customers canp understand. Sh d t d i f d tShow end-to-end processing of data.
Equipment procurement process Equipment Checked spec Deli very note Deli very note Get cost estima tes Accept deli very of equipment Check delivered items Valida te specification Specify equipment requir ed spec. spec. Or der Installa tion i t ti Spec. + supplier + estima teEquipment Choose supplier Place equipment order Install equipment Find suppliers Supplier da tabase Or der notifica tion instructions Order details plus estima te Supplier list Equipment spec. Accept deli vered Installa tion acceptance Ch k d d p blank or der for m equipment Equipment details Check ed and signed or der f orm Equipment da tabase
State machine models These model the behaviour of the system inThese model the behaviour of the system in response to external and internal events. They show the system’s responses to stimuli (Stimuli are events in the environment that influence behavior.)so are often used for modelling real-time systems. State machine models show systemsystem statesstates asState machine models show systemsystem statesstates as nodesnodes and eventsevents as arcsarcs between these nodes. When an e ent occ rs the s stem mo es from oneWhen 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.
State charts Allow the decomposition of a model into sub-models A brief description of the actions is includedA brief description of the actions is included following the ‘do’ in each state. Can be complemented by tablestables describingdescribing the states and the stimuli.
Microwave oven state table description State Description Waiting The oven is waiting for input. The display shows the current time.g g p p y 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 top g p y y 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.
Microwave oven model Full power Full pow er do: set power = 600 do: operate Full power Number Set time do: get number Operation Waiting do: display time Timer do: operate oven Half power Half power p Door Door closed Start do: get number exit: set time CancelTimer Enabled Door open Door closed Door openHalf power do: set power = 3 00 Waiting do: display time do: display 'Ready' Disabled do: display 'Waiting'
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 closedDoor closed The oven door switch is closed Start The user has pressed the start button Cancel The user has pressed the cancel button
Microwave oven operation C k Checking Time Operation Cook do: run generator do: check status g Turntable Emitter OK Timeout Done do: buzzer on f 5 Alarm do: display Turntable fault Emitter fault Timeout for 5 secs. do: display event Door open Cancel WaitingDisabled
Semantic data models Used to describe the logicallogical structurestructure ofof datadata processedprocessed by the system.pp y y An entity-relation-attribute model sets out the entities in the system the relationships betweenentities in the system, the relationships between these entities and the entity attributes Widely used in database design. Can readily be implemented using relational databases.
Library semantic model
Data dictionaries Data dictionaries are listslists ofof allall of the names used in the system models. Descriptions of the entities,y p , relationships and attributes are also included. AdvantagesAdvantages • Support name management and avoid duplication; • Store of organisational knowledge linking analysis, design and implementation; Many CASE workbenches support data dictionaries.
Data dictionary entries Name Description Type Date Article Details of the published article that may be ordered by people using LIBSYS. Entity 30.12.2002 authors The names of the authors of the article who may be due Attribute 30 12 2002authors The names of the authors of the article who may be due a share of the fee. Attribute 30.12.2002 Buyer The person or organisation that orders a copy of the article. Entity 30.12.2002 fee-payable- to A 1:1 relationship between Article and the Copyright Agency who should be paid the copyright fee. Relation 29.12.2002 Address (Buyer) The address of the buyer. This is used to any paper billing information that is required. Attribute 31.12.2002 y g q
Object models “Object", refers to a particular instance of a ClassClass Object models describe the system in terms ofObject 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 producedj y p • Inheritance models; • Aggregation models;• Aggregation models; • Interaction models.
Object models Natural ways of reflecting the realreal--worldworld entitiesentities manipulated by the systemp y y Object class identification is recognised as a difficult process requiring a deep understanding of theprocess requiring a deep understanding of the application domain Object classes reflecting domain entities are reusablereusable acrossacross systemssystems
Inheritance models 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 classesfrom one or more super-classes.
Object models and the UML Th UML i t d d t ti d i d b thThe UML is a standard representation devised by the developers of widely used object-oriented analysis and design methodsmethods. It has become an effective standard for object-oriented modellingmodelling. Notation Object classes are rectanglesrectangles ith the name at the top• Object classes are rectanglesrectangles with the name at the top, attributesattributes inin thethe middlemiddle sectionsection and operationsoperations inin thethe bottombottom section; • Relationships between object classes (knownknown asas associationsassociations) are shown as lines linking objects; • Inheritance is referred to as generalisation and is shown ‘upwards‘upwards’ rather than ‘downwards’downwards’ in a hierarchy.
Library class hierarchy
User class hierarchy
Multiple inheritance Rather than inheriting the attributes and services from a single parent class, a system which supportsg p , y pp multiple inheritance allows object classes to inherit fromfrom severalseveral supersuper--classesclassesfromfrom severalseveral supersuper--classesclasses.. 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.reorganisation more complex.
Multiple inheritance
Object behaviour modelling Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects.
Issue of electronic items
Structured methods Methods define a set of models, a process for deriving these models and rules and guidelines thatg g should apply to the models. CASE tools support system modelling as part of aCASE tools support system modelling as part of a structured method.
Method weaknesses They do not model non-functional system requirements.q They do not usually include information about whether a method is appropriate for a givenwhether a method is appropriate for a given problem. The may produce too much documentation. The system models are sometimes too detailed andy difficult for users to understand.
CASE workbenches A coherent set of tools that is designed to support related software process activities such as analysis,p y , design or testing. Analysis and design workbenches support systemAnalysis 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 modelseveral different types of system model.
An analysis and design workbench
Analysis workbench components Diagram editors Model analysis and checking toolsModel analysis and checking tools Repository and associated query language Data dictionary Report definition and generation toolsp g Forms definition tools I t/ t t l tImport/export translators Code generation tools
Project managementProject managementProject managementProject management
Topics covered Project Management activities Project planningProject planning Project scheduling Risk management
Software project management Concerned with activitiesactivities involved in ensuring that software is delivered onon timetime and onon scheduleschedule and in accordance with the requirements of the organisations developingrequirements 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.g p g
Software Project Management activities Proposal writing. Project planning and schedulingProject planning and scheduling. Project costing. Project monitoring and reviews. Personnel selection and evaluation. Report writing and presentations.
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;available; • An organisation may wish to develop employee skills on a software projecton a software project. Managers have to work within these constraints i ll h th h t f t i d t ffespecially when there are shortages of trained staff.
Project planning Probably the most time-consuming project management activity.g y Continuous activity from initial concept through to system delivery Plans must be regularly revisedto system delivery. 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.
Types of project plan Plan Description Quality plan Describes the quality procedures and standards that will b d i jbe used in a project. . Validation plan Describes the approach, resources and schedule used for system validation. Configuration management plan Describes the configuration management procedures and structures to be used. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development Describes how the skills and experience of the projectp plan. p p j team members will be developed.
Project planning process E t bli h th j t t i tEstablish 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 scheduleg Wait ( for a while ) Review project progress Revise estimates of project parametersRevise 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
The project plan The project plan sets out: • The resources available to the project;The resources available to the project; • The work breakdown; • A schedule for the work.
Project plan structure Introduction. Project organisationProject organisation. Risk analysis. Hardware and software resource requirements. Work breakdown. Project schedule. M it i d ti h iMonitoring and reporting mechanisms.
Activity organization Activities in a project should be organised to produce tangible outputs for management to judgep g p g j g progress. Milestones are the end point of a process activityMilestones are the end-point of a process activity. Deliverables are project results delivered to customers. The waterfall process allows for the straightforwardp g definition of progress milestones.
Project scheduling Split project into tasks and estimate time and resources required to complete each task.q p Organize tasks concurrently to make optimal use of workforceuse of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. Dependent on project managers intuition andp p j g experience.
The project scheduling process
Scheduling problems Estimating the difficulty of problems and hence the cost of developing a solution is hard.p g Productivity is not proportional to the number of people working on a taskpeople working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allowp y pp y contingency in planning.
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 ornot be too small. They should take about a week or two. Activity charts show task dependencies and the the critical path. Bar charts show schedule against calendar time.
Task durations and dependencies Activity Duration (days) Dependencies T1 8 2 1T2 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) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)
Activity network
Activity timeline- Gantt Chart
Staff allocation
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.
Software risks Risk Affects Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not available on schedule Size underestimate Project and product The size of the system has been underestimated. CASE tool under- performance Product CASE tools which support the project do not perform as anticipated Technology 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 process
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;p p ; Risk monitoring • Monitor the risks throughout the project;Monitor the risks throughout the project;
Risk identification Technology risks. People risksPeople risks. Organisational risks. Requirements risks. Estimation risks.
Risks and risk types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected.as expected. Software components that should be reused contain defects that limit their functionality. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. i d i i f ff i il blRequired 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 that 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 of the software is underestimated.
Risk analysis Assess probability and seriousness of each risk. Probability may be very low low moderate high orProbability may be very low, low, moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignificant.
Risk analysis (i) Risk Probability Effects Organisational financial problems force reductions in Low CatastrophicOrganisational financial problems force reductions in the project budget. Low Catastrophic It is impossible to recruit staff with the skills required for the project. High Catastrophic Key staff are ill at critical times in the project. Moderate Serious Software components that should be reused contain defects which limit their functionality. Moderate Serious Changes to requirements that require major design rework are proposed. Moderate Serious The organisation is restructured so that different ibl f h j High Serious management are responsible for the project.
Risk analysis (ii) Risk Probability Effects The database used in the system cannot process as Moderate Serious many transactions per second as expec ted. The time required to develop the software is underestimated. High Serious CASE tools cannot be integrated High TolerableCASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of requirements changes. Moderate Tolerable Required training for staff is not available. Moderate Tolerableq g 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 Insignificantg y g
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, g y p p that risk;
Risk management strategies (i) Risk Strategy Organisational financial problems Prepare a briefing document for senior management showing how th e project is making a very important contribution to the goals of the business. Recruitment problems Alert customer of potential difficulties and the possibility of delays, investigate 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-Defective components Replace potentially defective components with bought- in components of known reliability.
Risk management strategies (ii) Risk Strategy Requirements changes Derive traceability information to assess requirements change impact, maximise information hiding in the design. O i ti l P b i fi d t f i tOrganisational restructuring Prepare a briefing document for senior management showing how th e project is making a very important contribution to the goals of the business. Database Investigate the possibility of buying a higherDatabase performance Investigate the possibility of buying a higher- performance database. Underestimated development time Investigate buying in components, investigate use of a program generatordevelopment time program generator
Risk monitoring Assess each identified risks regularly to decide whether or not it is becoming less or more probable.g p Also assess whether the effects of the risk have changedchanged. Each key risk should be discussed at management progress meetings.
Risk indicators Risk type Potential indicators T h l L d li f h d f dTechnology Late delivery of hardware or support software, many reported technology problems People Poor staff morale, poor relationships amongst team member, job availabilityjob availability Organisational Organisational gossip, lack of action by senior management Tools Reluctance by team members to use tools, complaints about CASE tools demands for higher powered workstationsCASE tools, demands for higher-powered workstations Requirements Many requirements change requests, customer complaints Estimation Failure to meet agreed schedule, failure to clear reported d f tdefects
Chapter Review Questions 1.Explain different types of system model in details. 2.Define Context model. Draw a context model for library system. 3.Explain semantic data model with suitable example. 4.Describe the state machine model with example. 5 W it h t t5. Write short note on a. Ethnography b.Use case c.Sequence diagram d.CASE workbench e. Risk planning f. Data dictionaryp g y 6. Describe the software project management activities in details. 7. Explain the importance of planning and scheduling in software project management. 8. Discuss the importance of risk management in software project. Explain various risk management strategiesvarious risk management strategies.

More Related Content

PPTX
Design Model & User Interface Design in Software Engineering
byMeghaj Mallick
 
PPT
Object Oriented Design in Software Engineering SE12
bykoolkampus
 
PDF
Software process
byDr. Loganathan R
 
PDF
Chapter 5 software design
byPiyush Gogia
 
PDF
Domain Modeling
byHarsh Jegadeesan
 
PPTX
state modeling In UML
byKumar
 
PPTX
CS8592-OOAD-UNIT II-STATIC UML DIAGRAMS PPT
byleela rani
 
PPTX
Data and functional modeling
bySlideshare
 
Design Model & User Interface Design in Software Engineering
byMeghaj Mallick
 
Object Oriented Design in Software Engineering SE12
bykoolkampus
 
Software process
byDr. Loganathan R
 
Chapter 5 software design
byPiyush Gogia
 
Domain Modeling
byHarsh Jegadeesan
 
state modeling In UML
byKumar
 
CS8592-OOAD-UNIT II-STATIC UML DIAGRAMS PPT
byleela rani
 
Data and functional modeling
bySlideshare
 

What's hot

PPT
Analysis modeling
byInocentshuja Ahmad
 
PPT
Unit 1 - Introduction to Software Engineering.ppt
byDrTThendralCompSci
 
PPTX
Er diagrams presentation
byAkanksha Jaiswal
 
PPTX
Uml Presentation
bymewaseem
 
PPTX
Fundamental software engineering activities
bysommerville-videos
 
PPT
System Models in Software Engineering SE7
bykoolkampus
 
PPTX
Uml
byVishwa Mohan
 
PPTX
Use case diagram
byCity University
 
PPT
Formal Specification in Software Engineering SE9
bykoolkampus
 
PPT
Uml in software engineering
byMubashir Jutt
 
PPTX
Phased life cycle model
byStephennancy
 
PPTX
SRS(software requirement specification)
byAkash Kumar Dhameja
 
PPT
Analysis modeling & scenario based modeling
byBenazir Fathima
 
PPTX
object oriented methodologies
byAmith Tiwari
 
PPTX
Software Engineering by Pankaj Jalote
byGolda Margret Sheeba J
 
PPT
UML
byiQra Rafaqat
 
PPT
Top down design
byChaffey College
 
PPTX
CORBA
byMokshada Nayak
 
PPTX
Unified process model
byRyndaMaala
 
PPT
System models in distributed system
byishapadhy
 
Analysis modeling
byInocentshuja Ahmad
 
Unit 1 - Introduction to Software Engineering.ppt
byDrTThendralCompSci
 
Er diagrams presentation
byAkanksha Jaiswal
 
Uml Presentation
bymewaseem
 
Fundamental software engineering activities
bysommerville-videos
 
System Models in Software Engineering SE7
bykoolkampus
 
Uml
byVishwa Mohan
 
Use case diagram
byCity University
 
Formal Specification in Software Engineering SE9
bykoolkampus
 
Uml in software engineering
byMubashir Jutt
 
Phased life cycle model
byStephennancy
 
SRS(software requirement specification)
byAkash Kumar Dhameja
 
Analysis modeling & scenario based modeling
byBenazir Fathima
 
object oriented methodologies
byAmith Tiwari
 
Software Engineering by Pankaj Jalote
byGolda Margret Sheeba J
 
UML
byiQra Rafaqat
 
Top down design
byChaffey College
 
CORBA
byMokshada Nayak
 
Unified process model
byRyndaMaala
 
System models in distributed system
byishapadhy
 

Similar to Unit 4- Software Engineering System Model Notes

PPTX
8 system models
byAyesha Bhatti
 
PPTX
8 system models (1)
byAyesha Bhatti
 
PDF
Unit 3 system models
byAzhar Shaik
 
PPT
Requirements engineering process: Feasibility studies, requirements elicitati...
bysunilsrinivas10
 
PPT
Systemmodels
bysietk
 
PPT
SE - System Models
byJomel Penalba
 
PPT
Ch8
byphanleson
 
PDF
Requirements engineering process: Feasibility studies, requirements elicitati...
bysunilsrinivas10
 
PPT
ch07.ppt
byAbdulraufKhan29
 
PPT
2.2. Software cycle Models-System_Models.ppt
bydawarbaba
 
PDF
Systemprocessing 160107234141
byAbuulHassan2
 
PDF
Software engineering ,system modeing >>Abu ul hassan sahadvi
byAbuulHassan2
 
PPTX
System Modelling
byJennifer Polack
 
PPTX
Module 2 17CS45
bysweetheartshridevi
 
PPT
chapter-4-objected-oriented analysis and design with UML.ppt
byMemMem25
 
PDF
Software Engineering - Ch8
bySiddharth Ayer
 
PDF
System Modelling
byIanBriton
 
PPT
SECh78
byJoe Christensen
 
PPTX
Bridge
byIslamia Univeristy Bahawalpur Bahawalnagar
 
PPT
Modeling System Requirements
byAsjad Raza
 
8 system models
byAyesha Bhatti
 
8 system models (1)
byAyesha Bhatti
 
Unit 3 system models
byAzhar Shaik
 
Requirements engineering process: Feasibility studies, requirements elicitati...
bysunilsrinivas10
 
Systemmodels
bysietk
 
SE - System Models
byJomel Penalba
 
Ch8
byphanleson
 
Requirements engineering process: Feasibility studies, requirements elicitati...
bysunilsrinivas10
 
ch07.ppt
byAbdulraufKhan29
 
2.2. Software cycle Models-System_Models.ppt
bydawarbaba
 
Systemprocessing 160107234141
byAbuulHassan2
 
Software engineering ,system modeing >>Abu ul hassan sahadvi
byAbuulHassan2
 
System Modelling
byJennifer Polack
 
Module 2 17CS45
bysweetheartshridevi
 
chapter-4-objected-oriented analysis and design with UML.ppt
byMemMem25
 
Software Engineering - Ch8
bySiddharth Ayer
 
System Modelling
byIanBriton
 
SECh78
byJoe Christensen
 
Bridge
byIslamia Univeristy Bahawalpur Bahawalnagar
 
Modeling System Requirements
byAsjad Raza
 

More from arvind pandey

PDF
ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
byarvind pandey
 
PDF
Syllabus.pdf
byarvind pandey
 
PPTX
Network entites
byarvind pandey
 
PPTX
Transport layer
byarvind pandey
 
PPTX
Internet service provider and network backbone
byarvind pandey
 
PPTX
Core java complete ppt(note)
byarvind pandey
 
PDF
Unit 6- Development Evolution model
byarvind pandey
 
PDF
Unit 5- Architectural Design in software engineering
byarvind pandey
 
PDF
Unit 3- requirements for software development
byarvind pandey
 
PDF
Unit 2-software development process notes
byarvind pandey
 
PDF
Unit 1-overview of software engineering
byarvind pandey
 
PPT
Chapter1 computer introduction note
byarvind pandey
 
PDF
computer network fundamental note
byarvind pandey
 
PPTX
I have a dream
byarvind pandey
 
PPTX
brain.ppts
byarvind pandey
 
ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
byarvind pandey
 
Syllabus.pdf
byarvind pandey
 
Network entites
byarvind pandey
 
Transport layer
byarvind pandey
 
Internet service provider and network backbone
byarvind pandey
 
Core java complete ppt(note)
byarvind pandey
 
Unit 6- Development Evolution model
byarvind pandey
 
Unit 5- Architectural Design in software engineering
byarvind pandey
 
Unit 3- requirements for software development
byarvind pandey
 
Unit 2-software development process notes
byarvind pandey
 
Unit 1-overview of software engineering
byarvind pandey
 
Chapter1 computer introduction note
byarvind pandey
 
computer network fundamental note
byarvind pandey
 
I have a dream
byarvind pandey
 
brain.ppts
byarvind pandey
 

Recently uploaded

PDF
AI Chatbots and Prompt Engineering - by Ms. Oceana Wong
byagenticroom
 
PPTX
The Ides Of March Throughout History-- not just Caesar but also . . .
byBob Mayer
 
PDF
MEDINIPUR QUIZ PREMIER LEAGUE PRACTICE QUIZ SET
bySaheb Mallik
 
PPTX
Q3 WEEK 1 _ LAYERS OF THE EARTH SCIENCE 8
byRoyoMel
 
PPTX
DEVELOPMENTL BIOLOGY hormonal control of metamorphosis.
byKajal Kashyap
 
PDF
Major Agro Climatic Zones of India_fundamental of horticulture.pdf
bybisensharad
 
PDF
Approaches and Methods in Political Science -EVOLUTION OF POLITICAL THOUGHT -...
byDr Raja Mohammed T
 
PPTX
COMPUTER SECURITY MODELS - Frameworks that help organizations design secure s...
byAbhishek Sonker
 
PDF
Introductions Introductions Introductions
byaidanattema
 
PDF
Sample Research Instruments for Initial Survey.pdf
byThelma Villaflores
 
PDF
TNTEU- BD1TL Unit - 3 THEORY OF CONSTRUCTIVISM AND LEARNER CENTERED
byDr Raja Mohammed T
 
PDF
Optomery MCQ pdf/exam/pyq/joinquiz/..pdf
byAnmol Singh
 
PDF
SHS_Core_CAE_Q3_LE1 FOR THIRD [FINAL].pdf
bydulaymd1904
 
PDF
Photoperiod Classification of Vegetable Plants.pdf
bybisensharad
 
PDF
1. Doing Academic Research: Problems and Issues, 2. Academic Research Writing...
byProf. Vinod Kumar Kanvaria
 
PDF
EVOLUTION - Theories, Pre-Darwinism, Darwinism
byANAKHA JACOB
 
PPTX
How to Enter Opening Stock in Odoo 18 Inventory
byCeline George
 
PPTX
2. Classification of Drugs.pptx (Pharmacognosy department)
byBushraDeshpande
 
PPTX
introduction to clinical pharmacology.pptx
byAneetaSharma15
 
PDF
Palestinian, Israeli, Portuguese, Poetry
byDr. Ilyas Babar Awan
 
AI Chatbots and Prompt Engineering - by Ms. Oceana Wong
byagenticroom
 
The Ides Of March Throughout History-- not just Caesar but also . . .
byBob Mayer
 
MEDINIPUR QUIZ PREMIER LEAGUE PRACTICE QUIZ SET
bySaheb Mallik
 
Q3 WEEK 1 _ LAYERS OF THE EARTH SCIENCE 8
byRoyoMel
 
DEVELOPMENTL BIOLOGY hormonal control of metamorphosis.
byKajal Kashyap
 
Major Agro Climatic Zones of India_fundamental of horticulture.pdf
bybisensharad
 
Approaches and Methods in Political Science -EVOLUTION OF POLITICAL THOUGHT -...
byDr Raja Mohammed T
 
COMPUTER SECURITY MODELS - Frameworks that help organizations design secure s...
byAbhishek Sonker
 
Introductions Introductions Introductions
byaidanattema
 
Sample Research Instruments for Initial Survey.pdf
byThelma Villaflores
 
TNTEU- BD1TL Unit - 3 THEORY OF CONSTRUCTIVISM AND LEARNER CENTERED
byDr Raja Mohammed T
 
Optomery MCQ pdf/exam/pyq/joinquiz/..pdf
byAnmol Singh
 
SHS_Core_CAE_Q3_LE1 FOR THIRD [FINAL].pdf
bydulaymd1904
 
Photoperiod Classification of Vegetable Plants.pdf
bybisensharad
 
1. Doing Academic Research: Problems and Issues, 2. Academic Research Writing...
byProf. Vinod Kumar Kanvaria
 
EVOLUTION - Theories, Pre-Darwinism, Darwinism
byANAKHA JACOB
 
How to Enter Opening Stock in Odoo 18 Inventory
byCeline George
 
2. Classification of Drugs.pptx (Pharmacognosy department)
byBushraDeshpande
 
introduction to clinical pharmacology.pptx
byAneetaSharma15
 
Palestinian, Israeli, Portuguese, Poetry
byDr. Ilyas Babar Awan
 
In this document
Powered by AI

Overview of Unit-4 discussing system models and topics covered including context, behavioural, data, and object models.

Explains system modelling, types of models: external, behavioural, structural, data processing, composition, architectural, classification, and stimulus/response models.

Defines and illustrates context models depicting external perspectives, using ATM system context as an example.

Describes behavioural models, types including data processing models and state machine models, including data flow diagrams (DFDs).

State machine models' function in system response to events, with examples like microwave ovens breakdown and state charts.

Explains logical data structure representation using entity-relation-attribute models and data dictionaries which support analysis.

Describes object models focusing on object classes, inheritance models, and relationships, highlighting the use of UML for modeling.

Details on multiple inheritance complexities and interactions in object behavior using sequence diagrams.

Overview of project management in software development addressing planning, scheduling, and organizational requirements.

Discusses project planning's importance, types of plans, the planning process, and project scheduling strategies.

Risk management processes including identification, analysis, planning, and monitoring for project and product risks.

Outlines strategies to handle identified risks effectively through avoidance, minimization, and contingency planning.

Emphasizes the need for ongoing assessment of risks and identifying indicators to mitigate potential project issues.

A selection of review questions designed to assess understanding of system modeling, project management, and risk strategies.

Unit 4- Software Engineering System Model Notes

  • 1.
  • 2.
    Topics covered Context models BehaviouralmodelsBehavioural models Data models Object models CASE workbenches
  • 3.
    System modelling System modellinghelps the analystanalyst to understand the functionality of the system and modelsmodels are usedy y to communicatecommunicate with customerscustomers.. Different models present the system from differentDifferent models present the system from different perspectives •• ExternalExternal perspectiveperspective showing the system’s context or environment; Beha io ralBeha io ral perspecti eperspecti e sho ing the beha io r of the s stem•• BehaviouralBehavioural perspectiveperspective showing the behaviour of the system; •• StructuralStructural perspectiveperspective showing the system or data architecture.architecture.
  • 4.
    Model types DataData processingprocessingmodelmodel showing how the datadata isis processedprocessed at different stages. CompositionComposition modelmodel showing how entitiesentities areare composedcomposed of other entitiescomposedcomposed of other entities. ArchitecturalArchitectural modelmodel showing principal sub-systems. ClassificationClassification modelmodel showing how entitiesentities havehave commoncommon characteristicscharacteristics. Stimulus/responseStimulus/response model/Statemodel/State showing the system’s reaction to eventssystem s reaction to events.
  • 5.
    Context models-External perspectiveExternalperspective Context models are used to illustrate the operationaloperational contextcontext of a system - they show whatpp y y lies outsideoutside thethe systemsystem boundariesboundaries.
  • 6.
    The context ofan ATM system Security system Account da tabase Branch accounting system Auto-teller system Branch M i t Usage database Branch counter system Maintenance system
  • 7.
    Behavioural models Behavioural modelsare used to describe the overall behaviour of a system. Two types of behavioural model are: •• DataData processingprocessing modelsmodels that show how data•• DataData processingprocessing modelsmodels that show how data is processed as it moves through the system; •• StateState machinemachine modelsmodels that show the systems response to events.
  • 8.
    Process models Data flowmodels may be used to show the processes and the flowflow ofof informationinformation fromfrom oneonep processprocess toto anotheranother..
  • 9.
    Data-processing models Data flowdiagrams (DFDs) may be used to model the system’s data processing.y p g These show the processing steps as data flows through a systemthrough a system. DFDs are an intrinsic part of many analysis methods. Simple and intuitive notation that customers canp understand. Sh d t d i f d tShow end-to-end processing of data.
  • 10.
    Equipment procurement process Equipment Checked spec Delivery note Deli very note Get cost estima tes Accept deli very of equipment Check delivered items Valida te specification Specify equipment requir ed spec. spec. Or der Installa tion i t ti Spec. + supplier + estima teEquipment Choose supplier Place equipment order Install equipment Find suppliers Supplier da tabase Or der notifica tion instructions Order details plus estima te Supplier list Equipment spec. Accept deli vered Installa tion acceptance Ch k d d p blank or der for m equipment Equipment details Check ed and signed or der f orm Equipment da tabase
  • 11.
    State machine models Thesemodel the behaviour of the system inThese model the behaviour of the system in response to external and internal events. They show the system’s responses to stimuli (Stimuli are events in the environment that influence behavior.)so are often used for modelling real-time systems. State machine models show systemsystem statesstates asState machine models show systemsystem statesstates as nodesnodes and eventsevents as arcsarcs between these nodes. When an e ent occ rs the s stem mo es from oneWhen 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.
  • 12.
    State charts Allow thedecomposition of a model into sub-models A brief description of the actions is includedA brief description of the actions is included following the ‘do’ in each state. Can be complemented by tablestables describingdescribing the states and the stimuli.
  • 13.
    Microwave oven statetable description State Description Waiting The oven is waiting for input. The display shows the current time.g g p p y 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 top g p y y 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.
  • 14.
    Microwave oven model Fullpower Full pow er do: set power = 600 do: operate Full power Number Set time do: get number Operation Waiting do: display time Timer do: operate oven Half power Half power p Door Door closed Start do: get number exit: set time CancelTimer Enabled Door open Door closed Door openHalf power do: set power = 3 00 Waiting do: display time do: display 'Ready' Disabled do: display 'Waiting'
  • 15.
    Microwave oven stimuli StimulusDescription 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 closedDoor closed The oven door switch is closed Start The user has pressed the start button Cancel The user has pressed the cancel button
  • 16.
    Microwave oven operation Ck Checking Time Operation Cook do: run generator do: check status g Turntable Emitter OK Timeout Done do: buzzer on f 5 Alarm do: display Turntable fault Emitter fault Timeout for 5 secs. do: display event Door open Cancel WaitingDisabled
  • 17.
    Semantic data models Usedto describe the logicallogical structurestructure ofof datadata processedprocessed by the system.pp y y An entity-relation-attribute model sets out the entities in the system the relationships betweenentities in the system, the relationships between these entities and the entity attributes Widely used in database design. Can readily be implemented using relational databases.
  • 18.
  • 19.
    Data dictionaries Data dictionariesare listslists ofof allall of the names used in the system models. Descriptions of the entities,y p , relationships and attributes are also included. AdvantagesAdvantages • Support name management and avoid duplication; • Store of organisational knowledge linking analysis, design and implementation; Many CASE workbenches support data dictionaries.
  • 20.
    Data dictionary entries NameDescription Type Date Article Details of the published article that may be ordered by people using LIBSYS. Entity 30.12.2002 authors The names of the authors of the article who may be due Attribute 30 12 2002authors The names of the authors of the article who may be due a share of the fee. Attribute 30.12.2002 Buyer The person or organisation that orders a copy of the article. Entity 30.12.2002 fee-payable- to A 1:1 relationship between Article and the Copyright Agency who should be paid the copyright fee. Relation 29.12.2002 Address (Buyer) The address of the buyer. This is used to any paper billing information that is required. Attribute 31.12.2002 y g q
  • 21.
    Object models “Object", refersto a particular instance of a ClassClass Object models describe the system in terms ofObject 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 producedj y p • Inheritance models; • Aggregation models;• Aggregation models; • Interaction models.
  • 22.
    Object models Natural waysof reflecting the realreal--worldworld entitiesentities manipulated by the systemp y y Object class identification is recognised as a difficult process requiring a deep understanding of theprocess requiring a deep understanding of the application domain Object classes reflecting domain entities are reusablereusable acrossacross systemssystems
  • 23.
    Inheritance models Classes atthe top of the hierarchy reflect the common features of all classes. Object classes inherit their attributes and services from one or more super classesfrom one or more super-classes.
  • 24.
    Object models andthe UML Th UML i t d d t ti d i d b thThe UML is a standard representation devised by the developers of widely used object-oriented analysis and design methodsmethods. It has become an effective standard for object-oriented modellingmodelling. Notation Object classes are rectanglesrectangles ith the name at the top• Object classes are rectanglesrectangles with the name at the top, attributesattributes inin thethe middlemiddle sectionsection and operationsoperations inin thethe bottombottom section; • Relationships between object classes (knownknown asas associationsassociations) are shown as lines linking objects; • Inheritance is referred to as generalisation and is shown ‘upwards‘upwards’ rather than ‘downwards’downwards’ in a hierarchy.
  • 25.
  • 26.
  • 27.
    Multiple inheritance Rather thaninheriting the attributes and services from a single parent class, a system which supportsg p , y pp multiple inheritance allows object classes to inherit fromfrom severalseveral supersuper--classesclassesfromfrom severalseveral supersuper--classesclasses.. 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.reorganisation more complex.
  • 28.
  • 29.
    Object behaviour modelling Sequencediagrams (or collaboration diagrams) in the UML are used to model interaction between objects.
  • 30.
  • 31.
    Structured methods Methods definea set of models, a process for deriving these models and rules and guidelines thatg g should apply to the models. CASE tools support system modelling as part of aCASE tools support system modelling as part of a structured method.
  • 32.
    Method weaknesses They donot model non-functional system requirements.q They do not usually include information about whether a method is appropriate for a givenwhether a method is appropriate for a given problem. The may produce too much documentation. The system models are sometimes too detailed andy difficult for users to understand.
  • 33.
    CASE workbenches A coherentset of tools that is designed to support related software process activities such as analysis,p y , design or testing. Analysis and design workbenches support systemAnalysis 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 modelseveral different types of system model.
  • 34.
    An analysis anddesign workbench
  • 35.
    Analysis workbench components Diagrameditors Model analysis and checking toolsModel analysis and checking tools Repository and associated query language Data dictionary Report definition and generation toolsp g Forms definition tools I t/ t t l tImport/export translators Code generation tools
  • 36.
    Project managementProject managementProjectmanagementProject management
  • 37.
    Topics covered Project Managementactivities Project planningProject planning Project scheduling Risk management
  • 38.
    Software project management Concernedwith activitiesactivities involved in ensuring that software is delivered onon timetime and onon scheduleschedule and in accordance with the requirements of the organisations developingrequirements 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.g p g
  • 39.
    Software Project Managementactivities Proposal writing. Project planning and schedulingProject planning and scheduling. Project costing. Project monitoring and reviews. Personnel selection and evaluation. Report writing and presentations.
  • 40.
    Project staffing May notbe 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;available; • An organisation may wish to develop employee skills on a software projecton a software project. Managers have to work within these constraints i ll h th h t f t i d t ffespecially when there are shortages of trained staff.
  • 41.
    Project planning Probably themost time-consuming project management activity.g y Continuous activity from initial concept through to system delivery Plans must be regularly revisedto system delivery. 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.
  • 42.
    Types of projectplan Plan Description Quality plan Describes the quality procedures and standards that will b d i jbe used in a project. . Validation plan Describes the approach, resources and schedule used for system validation. Configuration management plan Describes the configuration management procedures and structures to be used. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development Describes how the skills and experience of the projectp plan. p p j team members will be developed.
  • 43.
    Project planning process Et bli h th j t t i tEstablish 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 scheduleg Wait ( for a while ) Review project progress Revise estimates of project parametersRevise 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
  • 44.
    The project plan Theproject plan sets out: • The resources available to the project;The resources available to the project; • The work breakdown; • A schedule for the work.
  • 45.
    Project plan structure Introduction. ProjectorganisationProject organisation. Risk analysis. Hardware and software resource requirements. Work breakdown. Project schedule. M it i d ti h iMonitoring and reporting mechanisms.
  • 46.
    Activity organization Activities ina project should be organised to produce tangible outputs for management to judgep g p g j g progress. Milestones are the end point of a process activityMilestones are the end-point of a process activity. Deliverables are project results delivered to customers. The waterfall process allows for the straightforwardp g definition of progress milestones.
  • 47.
    Project scheduling Split projectinto tasks and estimate time and resources required to complete each task.q p Organize tasks concurrently to make optimal use of workforceuse of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. Dependent on project managers intuition andp p j g experience.
  • 48.
  • 49.
    Scheduling problems Estimating thedifficulty of problems and hence the cost of developing a solution is hard.p g Productivity is not proportional to the number of people working on a taskpeople working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allowp y pp y contingency in planning.
  • 50.
    Bar charts andactivity 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 ornot be too small. They should take about a week or two. Activity charts show task dependencies and the the critical path. Bar charts show schedule against calendar time.
  • 51.
    Task durations anddependencies Activity Duration (days) Dependencies T1 8 2 1T2 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) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)
  • 52.
  • 53.
  • 54.
  • 55.
    Risk management Risk managementis 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.
  • 56.
    Software risks Risk AffectsDescription Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not available on schedule Size underestimate Project and product The size of the system has been underestimated. CASE tool under- performance Product CASE tools which support the project do not perform as anticipated Technology 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.
  • 57.
  • 58.
    The risk managementprocess 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;p p ; Risk monitoring • Monitor the risks throughout the project;Monitor the risks throughout the project;
  • 59.
    Risk identification Technology risks. PeoplerisksPeople risks. Organisational risks. Requirements risks. Estimation risks.
  • 60.
    Risks and risktypes Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected.as expected. Software components that should be reused contain defects that limit their functionality. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. i d i i f ff i il blRequired 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 that 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 of the software is underestimated.
  • 61.
    Risk analysis Assess probabilityand seriousness of each risk. Probability may be very low low moderate high orProbability may be very low, low, moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignificant.
  • 62.
    Risk analysis (i) RiskProbability Effects Organisational financial problems force reductions in Low CatastrophicOrganisational financial problems force reductions in the project budget. Low Catastrophic It is impossible to recruit staff with the skills required for the project. High Catastrophic Key staff are ill at critical times in the project. Moderate Serious Software components that should be reused contain defects which limit their functionality. Moderate Serious Changes to requirements that require major design rework are proposed. Moderate Serious The organisation is restructured so that different ibl f h j High Serious management are responsible for the project.
  • 63.
    Risk analysis (ii) RiskProbability Effects The database used in the system cannot process as Moderate Serious many transactions per second as expec ted. The time required to develop the software is underestimated. High Serious CASE tools cannot be integrated High TolerableCASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of requirements changes. Moderate Tolerable Required training for staff is not available. Moderate Tolerableq g 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 Insignificantg y g
  • 64.
    Risk planning Consider eachrisk 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, g y p p that risk;
  • 65.
    Risk management strategies(i) Risk Strategy Organisational financial problems Prepare a briefing document for senior management showing how th e project is making a very important contribution to the goals of the business. Recruitment problems Alert customer of potential difficulties and the possibility of delays, investigate 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-Defective components Replace potentially defective components with bought- in components of known reliability.
  • 66.
    Risk management strategies(ii) Risk Strategy Requirements changes Derive traceability information to assess requirements change impact, maximise information hiding in the design. O i ti l P b i fi d t f i tOrganisational restructuring Prepare a briefing document for senior management showing how th e project is making a very important contribution to the goals of the business. Database Investigate the possibility of buying a higherDatabase performance Investigate the possibility of buying a higher- performance database. Underestimated development time Investigate buying in components, investigate use of a program generatordevelopment time program generator
  • 67.
    Risk monitoring Assess eachidentified risks regularly to decide whether or not it is becoming less or more probable.g p Also assess whether the effects of the risk have changedchanged. Each key risk should be discussed at management progress meetings.
  • 68.
    Risk indicators Risk typePotential indicators T h l L d li f h d f dTechnology Late delivery of hardware or support software, many reported technology problems People Poor staff morale, poor relationships amongst team member, job availabilityjob availability Organisational Organisational gossip, lack of action by senior management Tools Reluctance by team members to use tools, complaints about CASE tools demands for higher powered workstationsCASE tools, demands for higher-powered workstations Requirements Many requirements change requests, customer complaints Estimation Failure to meet agreed schedule, failure to clear reported d f tdefects
  • 69.
    Chapter Review Questions 1.Explaindifferent types of system model in details. 2.Define Context model. Draw a context model for library system. 3.Explain semantic data model with suitable example. 4.Describe the state machine model with example. 5 W it h t t5. Write short note on a. Ethnography b.Use case c.Sequence diagram d.CASE workbench e. Risk planning f. Data dictionaryp g y 6. Describe the software project management activities in details. 7. Explain the importance of planning and scheduling in software project management. 8. Discuss the importance of risk management in software project. Explain various risk management strategiesvarious risk management strategies.