Informatics Exam Preparation PDF
Document Details
Uploaded by Deleted User
Tags
Summary
This document is a set of notes on informatics exam preparation. It covers topics such as CMMI capability levels, SPI framework elements, and risk management strategies. The notes also include a discussion of proactive and reactive risk management.
Full Transcript
[Informatics exam preparation\ \ list the names of the cmmi capability level (I,p,m,d,qm,o)] -level 0 - incomplete -level 1 - performed -level 2 - managed -level 3 - defined -level 4 - quantatively managed -level 5 - optimized [what are the element of spi framework] -set of charecteristics t...
[Informatics exam preparation\ \ list the names of the cmmi capability level (I,p,m,d,qm,o)] -level 0 - incomplete -level 1 - performed -level 2 - managed -level 3 - defined -level 4 - quantatively managed -level 5 - optimized [what are the element of spi framework] -set of charecteristics that must be present if an effective software process is to be achieved -method for assessing whether those charecteristics are present -mechanism for summarizing the result of any assessment -strategy for assisting in implementing those process charecteristics that have been found to be weak/missing [4ps management spectrum] -people -the most important element of a successful project -stakeholder concern and team dynamics ( communication,collaboartion, skill level among team members) -product -the software to be built -discussion that ensures product is built and has quality - unique product reqs, quality (ui,usability etc) -process -the set of framework activities and tasks needed to get job done -process selection and adaptation (agile and rm) -project -all the work required to make product reality -planning,scheduling,resource constraints,budget and scope control etc [why is a generic checklist a good idea? name the generic categories that should be assessed with any proactive risk assessment] -comprehensive coverage - it helps ensure that all potential risk areas are considered reducing the likelihood to overlook important factors -standardization - it provides a consistent framework for assessing risks across different projects -efficiency - it streamline the risk assessment process, saving time and effort by providing predefined categories and items to evaluate -facilitate communication - a shared checklist can help team discuss risk more effectively as everyone is using the same terms and categories **[generic categories]** -product size - risk associated with the overall size of product to be built/modified -business impact - \" associated with constraints imposed by management or marketplace -staff size and experience - \" overall tech and project exp of se team that will do the work -tech to be built - \" complexity of system to be built and newness of tech packed by the system -process definition - \"degree to which process has been defined -dev environment - \" availability and quality of tool to be used -customer characteristics - sophistication of customer and developer\'s ability to communicate with customer in timely manner [what are some of the advantages and disadvantages of proactive and reactive risk strategies] \- proactive \- potential risks are identified, their probability and impact assessed, then ranked on importance -software team establishes a plan for managing risk -primary objective - is to avoid but not all risks can be avoided and thus -team work on a contingency plan that will enable team to respond is a controlled and effective manner \- it is a se toll that can help reduce technical debt -reactive -involves reactive to risk only when the occur -3 levels -mitigation - planning additional resources in anticipation of fire fighting -fix on failure - resources are found and applied when risk strikes -crisis management - failure does not respond to applied resources, project is in jeopardy +-----------------------+-----------------------+-----------------------+ | | Reactive | proactive | +=======================+=======================+=======================+ | advantages | -less time planning | -better preparedness | | | and more time doing | | | | | -reduce technical | | | -focus on immediate | debt | | | issues | | | | | -reduce risk impact | | | -encounter an error | | | | that has not been | \- increased | | | encountered before | stakeholder | | | | confidence | | | -adaptability | | +-----------------------+-----------------------+-----------------------+ | disadvantages | -crisis management | \- time consuming | | | | | | | -lead to costly | -more time spent of | | | delays, rework and | thing that may not | | | compromised project | happen | | | quality | | | | | \- uncertain ROI | | | -can't handle it a | | | | new PM | | +-----------------------+-----------------------+-----------------------+ [what does sqa encompass] -an sqa process (planning, req analysis, design review, code review and testing) -specific quality assurance and quality control tasks -effective se practice -control all software work product and the change made to them -a procedure to ensure compliance with development standards -measurement and reporting mechanisms [describe the cost associated with software quality work (P,A,I,E)] -prevention cost -- quality planning ,formal technical reviews, test equipment, training -appraisal cost -- in-process and inter-process inspection, equipment calibration and maintenance and testing -internal failure cost -- rework, repair, failure mode analysis -external failure cost -- complaint resolution, product return and replacement, help line support and warranty work [what is an informal review and why is it effective than a formal technical review] -informal review include a simple desk check of a se work product with a collegue, a casual meeting (involving more than 2 people) with the purpose of reviewing a work product\ however since there is no advanced planning and preparation, no agenda or meeting structure and follow-up on the errors that were uncovered , the effectiveness of such review is lower than that of formal ones Ereview = Eprep + Eass + Erework ERRtot = Eminor + Emajor Error Density = Etot/WPS [what is the purpose of square process model] the square process model provides for a means of eliciting, categorizing, and prioritizing security requirements for software-intensive systems -its focus is to build security concepts into the early stages of dlc. -it can also be used for fielded systems and those undergoing improvements and modifications [discuss 5 charecteristics of a product quality according to iso 25010 standard that focus both on the static and dynamic nature of computer systems] -Security -- confidentiality, integrity ,accountability and authenticity -Reliability -- maturity, availability, fault tolerance, recoverability \- Functional suitability -- complete , correct , appropriate \- compatibility -- coexistence , interoperability -usability -- appropriateness, learnability, operability , error protection, aesthetics, accessibility -performance efficiency -- timing , resources , utilization , capacity -portability -- adaptability, install ability, replaceability -maintainability -- modularity, reusability, modifiability, testability [following popia principles] -Data subject participation -- those who's pi is processed have various rights in relation to that processing\ -information quality -- pi must be complete, accurate, up to date and not misleading -processing limitation -- processing must be with consent and purpose must be adequate and relevant( not excessive) -security safeguards -- steps must be taken to ensure confidentiality, integrity and security of pi [what is pi] any information relating to an identifiable, living ,natural person and where it is applicable , an identifiable existing juristic person [discuss the function of a risk table by explaining the process of setting up a risk table and the various levels and consideration that are taken in a risk assessment] -table includes: -risk description, category, probability, impact (1-4) -- table sorted by impact and probability 1)risk identification 2)risk analysis -- evaluating identified risks to determine likelihood of occurrence and potential impact 3)risk prioritization -rank based on severity 4)risk mitigation planning -- develop strategies to reduce likelihood and impact of high-priority risks 5)monitoring and control -- continuously tracking risks through out project lc to detect any change in statuses -attempts to rate each risk in 2 ways 1)likelihood or probability that the risk is real 2)the consequences of associated risk -for each risk 1)establish a scale that reflects the perceived likelihood of a risk 2)outline the consequences of the risk 3)estimate the impact of the risk on the project and product -impact values -1: catastrophic -2: critical -3: marginal -4: negligible 4)assess the overall accuracy of the risk projection so that there will be no misunderstanding [describe the process that was needed to approve the required change to the software] -the change to the project and the impact on the project has to be evaluated -the change has to be managed to minimize errors -the change control has to be signed \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- [Elements of sqa] -review and audits -- early discovery of errors -testing -change, vendor, security, risk management -education -safety -error collection and analysis Sqa group is responsible for : qa planning, oversight, record keeping , analysis and reporting Software quality: an effective software process applied in a manner that creates a useful product that provides measurable value for those who produces it and those who use it [how does a manager avoid a frenzied work environment] [verification and validation] verification -- refers to the correct implementation of functions validation -- refers to the correct built according to requirements [Risk management framework(RFM) steps for security] -categorize -select -implement -assess -authorize -monitor [describe all activities that must occur in order to produce a risk mitigation, monitoring and management plan] [how is software scope defined] it describes\ -fns and features to be delivered to end-users -data io -content presented to users of using the software -performances, constraints, interfaces and reliability that bound the system Defined using 2 techniques -a narrative description -- developed after communication with stakeholders \- a set of use-cases developed by end-users [what are the benefits of software refactoring] [what is the objective of project planning] -5 major activities -estimation, scheduling, risk analysis,qmp,cmp [what is forward engineering] [why is feasibility assessment part of the planning process] [W5hh] -why is the system being developed? -- does the business purpose justify the expenditure of people, time and money? -what will be done? -- the task set required for the project defined -when will it be accomplished? -- team establishes a project schedule with milestones -who is responsible? -- the roles and responsibilities of each member of the team is defined -where are they(responsibilities) organizationally located? -- not all responsibilities are for software team some are for customers, users and stakeholders -how will the job be done technically and managerially? - -how much of each resource will be needed? [how are project risks different from technical risks] [scm activities are developed to:] [4 sources of change] -new business/market conditions -- dictate change in product reqs or business rules -new stakeholders needs/demand -reorganization/business growth or downsizing causes changes in project priorities or se team structure -budgetary/scheduling constraints cause redefinition of system product [4 elements of a config system -- by susan dart] -component elements -process elements -construction elements -human elements 5 scm tasks : identification, vc ,cc, config audit, reporting Measures, Metrics, and Indicators A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of attributes of a product or process. A metric is a quantitative measure of the degree to which a system, component, or process possesses a given attribute. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself. Key performance indicators (KPIs) are metrics that are used to track performance and trigger remedial actions when their values fall in a predetermined range. Attributes of Effective Metrics Simple and computable. It should be relatively easy to learn how to derive the metric. Empirically and intuitively persuasive. Satisfies the engineer's intuitive notions about the product attributes. Consistent and objective. The metric should yield results that are unambiguous. (not open for different interpretations) Consistent in its use of units and dimensions. Computation of the metric should not lead to bizarre combinations of units. Programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. Effective mechanism for quality feedback. Should provide a software engineer with information that can lead to a higher quality end-product. Team team team team team team team Team Leaders Kouzes exemplary practices for technology leaders: Model the way. Leaders must practice what they preach. They demonstrate commitment to team and project by shared sacrifice. Inspire and shared vision. Motivate team members to tie their personal aspirations to team goals. Involve stakeholders early. Challenge the process. Encourage team members to experiment and take risks by helping them generate frequent small successes while learning from their failures. Enable others to act. Increase the team's sense of competence through sharing decision making and goal setting. Encourage the heart. Build community (team) spirit by celebrating shared goals and victories (individual and team). [Why Are Projects Late?] Unrealistic deadline established by someone outside the software team and forced on managers and practitioners on the group. Changing requirements not reflected in schedule changes. An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job. Predictable and/or unpredictable risks that were not considered when the project commenced. Technical difficulties that could not have been foreseen in advance. Human difficulties that could not have been foreseen in advance. Miscommunication among project staff that results in delays. Failure by project management to recognize that the project is falling behind schedule and lack of action to correct the problem. [team toxicity factors] Frenzied work atmosphere team members waste energy and lose focus on work objectives. High frustration caused by personal, business, or technological factors causing team member friction. Fragmented or poorly coordinated procedures poorly defined or improperly chosen process model. Unclear definition of roles resulting in lack of accountability and resultant finger-pointing. Continuous and repeated exposure to failure leads to a loss of confidence and a lowering of morale. Factors Affecting Software Team Structure Difficulty of the problem to be solved. Size of the resultant program(s) in lines of code or function points. Team lifetimes - time that the team will stay together. Degree to which the problem can be modularized. Required quality and reliability of the system to be built. Rigidity of the delivery date. Communication (degree of sociability) required. Risk Management Principles Maintain a global perspective - view software risks within the context of system and the business problem. Take a forward-looking view - think about the risks that may arise in the future; establish contingency plans. Encourage open communication - if someone states a potential risk, don't discount it. Integrate - a consideration of risk must be integrated into the software process Emphasize a continuous process - team must be vigilant throughout the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved. Develop a shared product vision - if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur. Encourage teamwork - the talents, skills and knowledge of all stakeholders should be pooled