Spm2

271 views
198 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
271
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Spm2

  1. 1. Žiga Turk, Assoc.Prof. ziga.turk@uni-lj.si CMIT 558 Map University of Ljubljana, Faculty of Civil and Geodetic Engineering Istanbul Technical University IT strategies construction MBA in Construction Informatics in Construction Management as a new economy visions, strategies, software product requirements engineering databases CMIT 558: limits of Web Information Systems for Construction technology technologies, Management analysis and Java, XML document design management modelling client-server product method technology modelling computer process development integrated Software Engineering modelling construction thesauri new ways of classification working distance systems information use working retrieval management 2Learning objective Context how information systems are designed software engineering management is involved as client IT management, the modelling method IT specialists as suppliers process models information systems development as an product models engineering process software engineering civil engineering some similarities one of a kind product work on multiple projects 3 4
  2. 2. Content Literature What is software engineering Pressman, Software Engineering, A Practitioner’s Software as a process Approach, McGraw Hill Software project management Rational Website www.rational.com Software metrics (short) Risk management Analysis and design (separate presentations) structured method UML (object oriented method) Lab: UML 5 6Software Engineering — Some Software CharacteristicsIntroduction What is Software Engineering (SE)? Software is The process of building a software product. engineered or developed, not Some questions to put SE in perspective: manufactured in What are the sizes of some typical software products? the traditional Maple.exe = 1.3 Mbytes.-- System over 3.8 Mbytes Mbytes.-- sense. Netscape.exe = 1.26 megabytes. Software does not Microsoft Office 97 > 180 megabytes. wear out in the How many people would it take to build these in same sense as 1 year? 2? hardware. What would you do if a bug could cost lives and $2 Right: hardware billion? failure rate What would you do if a delay could cost $100’s of millions? 7 8
  3. 3. Some Software Characteristics Some Software Characteristics In theory, software Reality is more like does not wear out this. at all. Most serious corporations control BUT, and constrain Hardware changes. upgrades. Most software is Software upgrades. custom built, and customer never really Right: failure curve knows what she/he for software wants Right: actual failure rate for software 9 10Some General Approaches Software is complex Develop and use good engineering practices for adding another button to an alarm clock costs building software. money during manufacturing of each piece Make heavy use of reusable software the cost is manufacturer’s components. Use modern languages that support good adding a butting to a program may cost software development practices, e.g., Ada95, something during software development (or not) Java. consequence is more complex software Use 4th generation languages. more difficult to use But, almost everything is a two-edged sword. the user pays Consider long term tool maintenance. Right now, this is a major problem for NASA. 11 12
  4. 4. Software Myths Software Myths Myth: It’s in the software. So, we can easily Myth: I can’t tell you how well we are doing until I get change it. parts of it running. Reality: Requirements changes are a major cause of Reality: Formal reviews of various types both can give good software degradation. information and are critical to success in large projects. Myth: We can solve schedule problems by Myth: The only deliverable that matters is working code. Reality: Documentation, test history, and program configuration adding more programmers. are critical parts of the delivery. Reality: Maybe. It increases coordination efforts and may slow things down. Myth: I am a (super) programmer. Let me program it, and I will get it done. Myth: While we don’t have all requirements in Reality: A sign of immaturity. A formula for failure. Software writing yet, we know what we want and can projects are done by teams, not individuals, and success start writing code. requires much more than just coding. Reality: Incomplete up-front definition is the major up- cause of software project failures. 13 14Software Myths Software as a Process Myth: Writing Definition: Software Engineering is the code is the major establishment and use of sound engineering part of creating a principles in order to obtain economically software product. Reality: Coding software that is reliable and works efficiently on may be as little real machines. as 10% of the effort, and 50 - Software Engineering is a layered technology. 70% may occur after delivery. Below: Impact of change. 15 16
  5. 5. A Layered Technology Some Generic Engineering Phases: Building Tools System or information engineering (leading to Editors requirements) Design aids Software project planning Compilers Requirements analysis Computer Aided Software Engineering (CASE) Development Methods Software design Includes standards (formal or informal) Coding May include conventions, e.g., low level such as conventions, Testing naming, variable, language construct use, etc. Migration May involve design methodologies. methodologies. Maintenance 17 18Some Generic Engineering Typical activities in these phasesPhases: MaintenanceMaintenance Project tracking and control Formal reviews Correction -- bugs will appear Software quality assurance Adaptation -- to changing operating systems, Configuration management CPU’s, etc. versions, group of versions = configuration Enhancement -- changing customer needs Documentation Prevention -- software reengineering Reusability management Measurements Risk management 19 20
  6. 6. SEI Software Process Maturity Software Process ModelsModel Level 1: Initial -- The software process is characterized phases of problem as ad hoc, and occasionally even chaotic. Few processes solving loop defined. Level 2: Repeatable -- Basic project management processes established to track cost, schedule and functionality. Level 3: Defined -- Process for both management and engineering is documented, standardized and integrated. problem solving Level 4: Managed -- Detailed measures of the process applied recursively and product quality collected. Both are quantitatively understood and controlled. Level 5: Optimizing -- Continuous process improvement enabled by quantitative feedback and testing innovative ideas.SEI = Software Engineering Institute, CMU. 21 22Process models Waterfall Model Waterfall Rapid Prototyping System/Information Engineering Evolutionary incremental Requirements Requirements Analysis Analysis Design Design Code Code spiral component assembly concurrent development Test Test Other formal 4GL process technology Maintain Maintain 23 24
  7. 7. The Rapid Prototyping Model Evolutionary process models: Incremental Model 25 26Evolutionary Process Models: Evolutionary Process Models:The Spiral Model Component Assembly Model 27 28
  8. 8. Evolutionary Process Models: Other ModelsConcurrent Development Model Formal Methods Rigorous mathematical representation of requirements Provides basis for automatic verification test generation Fourth Generation Techniques Use code generators to produce specific parts of product Process Technology Provides a variety of tools to aid software developers, e.g., workload flow, configuration management, quality assurance management, etc. 29 30Project Management Concepts Why Do Major Engineering Undertakings Often Fail?Why is project management important? Large projects often fail for two principal reasons: Cost Communication: Inadequate communication DoD already spending $30 billion annually on leads to project failure software in late 80’s Coordination: Lack of communication implies The US spent $150 billion that the team can not coordinate. Thus each $225 billion worldwide group moves in an independent direction and Projects frequently fail or have severe difficulties the project will grind to a halt. “New” FAA air traffic control system They don’t meet specifications no news to civil engineers! They take much longer than expected 31 32
  9. 9. The Spectrum of Management PeopleConcerns Effective Software management encompasses The Players -- It is important to recognize the three main areas: different categories of people involved in a large People software project. Problem Senior Managers - who define business issues. Process Project Managers - who plan, motivate, organize and control the practitioners Practitioners - who deliver the technical skill that are necessary to engineer the project Customers - who specify the requirements End users - who interact with the software once it is released. 33 34Team Leadership -- Organisational Models:A Critical Item Marilyn Mantei Model The Problem:The best programmers often make Democratic decentralized (DD). -- Does not have a poor team leaders. defined leader. “Task Coordinators” are appointed to assure that a particular job is to be executed. These are Different skills are required. later replaced by other “Task Coordinators” as new tasks Technical leadership model arise. Motivation - the ability to encourage technical people Controlled decentralized (CD) -- Has a defined leader to produce to their best ability. who coordinates tasks, and secondary leaders who carry Organization - the ability to mold existing processes out subtasks. Problem solving is done by the group, that will enable the initial concept to be translated implementation is done by subgroups. into reality. Controlled Centralized (CC) - Top-level problem solving Top- Ideas and Innovation - the ability to invite and team coordination managed by the team leader. creativeness even within a set of restrictions. The communication between the leader and members is vertical. 35 36
  10. 10. Project Features Impacting Impact of Project CharacteristicsOrganization Difficulty of problem to be solved. democratic decentralised Expected size of the resultant program. controlled The time the team will remain together. decentralised The degree to which the problem can be controlled modularized. centralised The required quality and reliability of the system. The rigidity of the delivery date. The degree of communication required for the project. 37 38Underlying Organizational Factors: How Do We Communicate?Matrix model The organization has divisions organized by Informally - Good phone/electronic service, a skills, e.g., engineering, safety and mission clear definition of group interdependencies and assurance, human factors, etc. good relationships help encourage Projects “rent” people from the divisions, as communication needed. Issues Who evaluates person for raises? Independence of reporting for safety & quality issues? Who is boss? 39 40
  11. 11. Project Coordination techniques Value and use of coordination and communication techniques Formal, impersonal approaches - software engineering documents and deliverables, technical memos, project milestones, schedules and control tools Formal interpersonal procedures - quality assurance activities - reviews and design and code inspections Informal, interpersonal procedures - group meetings Electronic communication - Email, bulletin boards, web sites, extension and video conferences Interpersonal network - discussions with those outside of the project. 41 42Summary Analysis and Design Software project management is an umbrella activity that continues throughout the life cycle Two primary methods today of the system. Structured Analysis Software management includes the people, the Object-oriented analysis Object- problem, and the process. Some important considerations The most critical element in all software system projects is the people. The team can have an Analysis products must be maintainable number of structures that effect the way work is Effective partitioning is essential accomplished. Graphics should be used whenever possible However, complete, consistent problem Distinguish between logical and implementation definition and an effective process are also essential ingredients. Separate presentations! 43 44
  12. 12. Žiga Turk, Assoc.Prof. Software Process and Project ziga.turk@uni-lj.si University of Ljubljana, Faculty of Civil and Geodetic Engineering Metrics: Outline Istanbul Technical University MBA in Construction Informatics in Construction Management Software Metrics Domains: product metrics CMIT 558: project metrics Information Systems for Construction Management process metrics Software Measurement size-oriented metrics size- function-oriented metrics function- End of the short metrics for Software Quality version 46Measure, Metrics, and Indicator Use of Software Metrics Measure -- Provides a quantitative indication of Use common sense and organizational sensitivity. the extent, amount, dimensions, capacity, or Provide regular feedback to individuals and teams. size of some product or process attribute (1000 Don’t use metrics to appraise individuals. lines) Set clear goal and metrics. Metrics -- A quantitative measure of the degree Never use metrics to threaten individuals or teams to which a system, component, or process Problems != negative. These data are merely an possesses a given attribute (40%) indicator for process improvement. Don’t obsess on a single metric to the exclusion of other Software Metrics -- refers to a broad range of important metrics. measurements for computer software Do not rely on metrics to solve your problems. Indicator -- a metric or combination of metrics Beware of people performing to metrics rather than that provide insight into the software process, a product quality or safety. software project, or the product itself. 47 48
  13. 13. Typical Causes of Product Measures of Software Quality:Defects Correctness and Maintainability Correctness is the degree to which the software performs its required function. The most common measure for correctness is defects per KLOC Maintainability is the ease that a program can be corrected: adapted if the environment changes enhanced if the customer desires changes in requirements based on the time-oriented measure mean time to time- change. 49 50Measures of Software Quality: SummaryIntegrity and Usability Integrity is a system’s ability to withstand Metrics are a tool which can be used to improve attacks (both accidental and intentional) on its the productivity and quality of the software security system Usability - an attempt to quantify “user Process metrics takes a strategic view to the effectiveness of a software process friendliness” physical/intellectual requirement to learn ... Project metrics are tactical that focus on project work flow and technical approach time required to become moderately efficient Size-oriented metrics use the line of code as a the net increase in productivity normalizing factor user attitudes toward system Function-oriented metrics use function points Quality metrics are correctness, integrity, maintainability, and usability. 51 52
  14. 14. Software Project Planning Software ScopeSteps to Software Planning: What scope means: Functions Define Software Scope Literally refers to all functions performed by a system Determine Resources Performance Create Project Estimates Refers to processing and response time requirements Make or buy decision Constraints Limits placed on the software by external hardware, available memory or existing systems Interfaces Reliability 53 54Scope Scope Information Obtaining the information Some typical questions Communication, communication, communication!!! Overall Goals Who’s request Meet with customer as often as needed. What benefit Have free form discussion Who else has solution Try to understand his/her goals/constraints, not just Understanding The Problem what she/he thinks they want. What output What Problem Beware if ones provides detailed written What Issues specifications on what they want. What Constraints The problem is that those writing them probably Effectiveness of Meeting didn’t fully understand, and they will change. Are answers official Are my questions relevant Other sources of Info. 55 56
  15. 15. Scoping - Subsequent Meetings Human Resources Begin high level planning Scope and skills required Know the capabilities of existing software and staff Organizational position and specialty must both Joint teams of customer and developers/analysts be considered Checklist of items to cover As estimate of development effort is essential to Organization of Information determine the number of people required for the Get everything down with diagrams project. Create and save transcripts of Meetings Possibly use Web. 57 58Reusable Software Resources Software Engineering Environmental Resources Compilers Off-the-shelf components Editors The validity pedigree is critical Design tools Full experience components Configuration management tools Partial experience components Management tracking tools New validation will have to be performed Problem Reporting And Corrective Action (PRACA) tools Documentation tools Hardware resources Network support 59 60
  16. 16. Software Project Estimation Software Project Estimation Estimation critical -- software costs usually Precise estimation is difficult. So, make three dominate project. estimates: Categories of estimation techniques optimistic Base estimates on similar projects most likely Use simple decomposition (possibly in combination pessimistic with other methods Use one or more empirical models, I.e., Then combine as: • For example # of people = LOC ÷(Duration*(LOC/PM)) LOC = line of code (S 4*S EV = (Sopt + 4*Sm + Spess)/6 PM = person month 61 62Estimation Table Process Based Estimation Decompose the process into a set of activities or tasks Estimate effort or cost to perform each task Estimate cost cost of each function May be done using LOC and FP estimation or separatelySuppose: If estimated separately, then there are two or three distinct cost estimates 620 LOC/PM Reconcile differences $8,000/PM If radically different, perhaps based upon historical data. Then, • problem is not well understood, or • productivity data is obsolete, orEst. Cost = 33,200*$8,000/620 = $421,000 63 • the models have not been used correctly. 64
  17. 17. Summary Risk Management Project planner must estimate three things: Introduction how long project will take Risk Identification how much effort will be required Risk Projection how many people will be required Risk Mitigation, Monitoring, and Must use decomposition and empirical modeling Management Most empirical techniques need to be calibrated to individual situations. Safety Risks and Hazards Use multiple techniques to gain confidence in result The RMMM plan SEI Technical Reviews Summary 65 66Introduction Introduction Risk management is a process that is used Robert Charette presented the following extensively for various purposes conceptual definitions of risk: Recall earlier questions raised about safety, costs, Risk concerns future happenings etc. Risk involves change, such as changes of mind, According to “Webster’s Seventh New Collegiate opinion, action or places Dictionary”, risk is defined as a: Risk involves choice, and the uncertainty that choice “possibility of loss or injury” itself entails “the chance of loss or the perils to the subject matter Risk Characteristics : of an insurance contract” and uncertainty: may or may not happen “the degree of probability of such loss.” loss: unwanted consequences 67 68
  18. 18. Introduction Types of risk strategies Management is Reactive Proactive “the act or art of managing” and Software team does Begins long before nothing about risks until technical work is initiated “judicious use of means to accomplish an end”(1) something goes wrong Identification of potential RISK MANAGEMENT can be defined as: “fire fighting mode” risks (studies of probability, At best, monitors the impact and priorities) “A logical process for identifying and analyzing projects for likely risks Objective: AVOID RISK leading to appropriate methods for handling and Responds are in a monitoring exposures to loss” controlled and effective manner Risk management deals with: Systematic identification of an exposure to the risk of loss, & Making decisions on the best methods for handling these exposures to minimize losses 69 70Kinds of risks Risk Identification Project Risks Risk identification is a systematic attempt to budgetary, schedule, personnel, resource, customer specify threats to the project plan Technical Risks design, implementation, interfacing, verification Identify known and predictable risks Business Risks Generic Product-specific market, strategic, management,budget Product size Business impact Customer characteristics What characteristics of Process definition Risks may be: this product may threaten Development environment our project plan? Technology to be built Known Staff size and experience Predictable Unpredictable Risk Item List 71 72
  19. 19. Risk Identification Product Size Risk : product Estimated size of the product in LOC or FP? business Percentage deviation in size of product from average for previous products? customer Number of users/projected changes to the requirements technlogy for the product? Amount of reused software? 73 74Business Impact risks: Customer related risks: Effect of this product on the company revenue? Have you worked with the customer in the past? Visibility of this product to senior management? Does the customer have a solid idea of what is Amount & quality of product documentation to be required? produced? Governmental constraints on the construction of the Will the customer agree to have meetings? product? Is the customer technically sophisticated in the product area? Does the customer understand the software process? 75 76
  20. 20. Technology Risks: Process Risks Is the technology to be built new to your Does senior management support a written policy statement that emphasizes a standard process for software development ? organization? Is there a written description of the software process to be used? used? Does the SW interface with new or unproven Is the software process used for other projects ? HW/SW? Is configuration management used to maintain consistency among system/software requirements, design, code and test? Do requirements demand creation of new Is a procedure followed for tracking subcontractor performance? components ? Are facilitated application specification techniques used to aid in communication between the customer and developer ? Do requirements impose excessive performance Are specific methods used for software analysis? constraints ? Do you use specific method for data and architectural design? Are software tools used to support the software analysis and design? Are tools used to create software prototypes? 77 Are quality/productivity metrics collected for all software projects? projects? 78Development Environment Risks: Risk Associated with Staff Size and Experience: Is a software project/process management tool Are the best people available? available? Do the people have the right combination of Are tools for analysis and design available?? skills? Are testing tools available and appropriate for Are staff committed for entire duration of the the product? project? Are all SW tools integrated with one another? Do staff have the right expectations about the Have members of the project team received job at hand? training in each of the tools? Will turnover among staff be low enough to allow continuity? 79 80
  21. 21. Risk Components and Drivers Risk Identification Table(U.S. Air Force guidelines) COMPONENTS Performance risk: the degree of uncertainty that PERFORMANCE SUPPORT COST SCHEDULE the product will meet its requirements and be fit CATEGORY Failure to meet the requirements would Failure results in increased costs and for its intended use 1 schedule delays with expected values in result in mission failure excesss of $500k CATASTROPHIC Significant Nonresponsive or Significant financial Unachievable degradation to Cost risk: the degree of uncertainty that the 2 unsupportable shortages, budget nonachievement of technical performance software overrun likely delivery date project budget will be maintained Failure to meet the requirements would Failure results in operational delays 1 degrade system performance to a point and/or increased costs with expected where misssion success is questionable values of $100k to $500k CRITICAL Support risk:the degree of uncertainty that the Some reduction in Minor delays in Some shortage of Possible slippage in 2 software financial resources, technical performance modifications possible overruns delivery date software will be easy to correct, adapt, and Failure to meet the requirements would Cost, impacts, and/or recoverable 1 result in degradation of secondary schedule slips with expected value of $1 enhance MARGINAL misssion to $100K Minimal to small Responsive Sufficient financial Realistic, 2 reduction in technical Schedule risk: the degree of uncertainty that the performance software support resources achievable schedule Failure to meet the requirements would Error in minor cost and/or schedule 1 create inconvenience or nonoperational impact with expected value of less than NEGLIGIBLE project schedule will be maintained impact $1k No reduction in Easily supportable Possible budget Early achievable 2 technical performance software underrun delivery date 81 82Risk Projection Risk Projection Also called risk estimation, attempts to rate each risk in two ways: Risks Category Probability Impact RMMM Likelihood (probability) Size estimate may be significantly low PS 60% 2 Larger number of users than planned PS 30% 3 Consequences Less reuse than planned PS 70% 2 End users resist system BU 40% 3 Delivery deadline will be tightened BU 50% 2 Develop a risk table Funding will be lost CU 40% 1 A risk table provides a project manager with a simple technique Customer will change requirements PS 80% 2 for risk projection Technology will not meet expectations TE 30% 1 Lack of training on tools DE 80% 2 For each identified risk, list likelihood, consequence and impact impact Staff inexperienced ST 30% 2 Risk Assessment: Examine the accuracy of the estimates Staff turnover will be high ST 60% 2 . that were made during risk projection. A risk referent . . level must be defined and the referent point or break point should be established 83 84
  22. 22. Risk Matrix Risk Mitigation, Monitoring, and Management L 5 An effective strategy must consider three issues: I risk avoidance, k risk monitoring, and 4 risk management and contingency planning. A proactive approach e to risk avoidance is the best strategy. l 3 Develop a plan for risk mitigation. For example: assume I that high staff turnover is noted as a project risk r1, some h 2 of the possible steps to be taken are these: o meet with current staff to determine causes for turnover o 1 assume turnover will occur and develop techniques to ensure d continuity when people leave. 1 2 3 4 5 define a backup staff member for every critical technologies. Consequences 85 86Risk Mitigation, Monitoring, and Safety Risks and HazardsManagement As the project proceeds, the following factors can be monitored: Software safety and hazard analysis are general attitude of team members based on project pressures, software quality assurance activities that focus the degree to which the team has jelled, on the identification and assessment of potential interpersonal relationship among team members, hazard that may impact software negatively and availability of jobs within the company and outside it cause an entire system to fail. In addition of these factors, the project manager should monitor the effectiveness of risk mitigation steps. Risk management and If hazards can be identified early in the software contingency planning assumes that mitigation efforts have failed engineering process, software design features and that the risk has become reality. can be specified that will either eliminate or control potential hazards. 87 88
  23. 23. SEI Risk Management Paradigm Summary Risk analysis is an important part of most software projects. a) Identify Risk analysis requires a significant amount of project b) Analyze planning effort. c) Plan d) Track Understanding risk helps you know where to commit your e) Control resources. f) Communicate If you don’t actively attack the risks, they will actively attack you. Major projects should all have a risk management plan.. 89 90

×