SE101 - Software Engineering 1 Summary PDF

11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER WEEK 3 - SOFTWARE AND SOFTWARE discover and correct errors that might ENGINEERING...

11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER WEEK 3 - SOFTWARE AND SOFTWARE discover and correct errors that might ENGINEERING otherwise go undetected. (addtl) *Process Flow* Umbrella Activities of Process Framework  Framework activity - populated by a set of software engineering actions.  Software engineering action - defined by a task set that identifies the work tasks that are UNIFIED PROCESS to be completed.  attempt to draw on the best features and  Work products - will be produced, characteristics of traditional software process  Quality assurance points - will be required models, but characterize them in a way that  Project milestones - will be used to indicate implements many of the best principles of agile progress software development  recognizes the importance of customer * After incremental process model communication and streamlined methods for Prototyping. Often, a customer defines a set of describing the customer’s view of a system. It general objectives for software, but does not identify emphasizes the important role of software detailed requirements for functions and features. In architecture and “helps the architect focus on other cases, the developer may be unsure of the the right goals, such as understandability, efficiency of an algorithm, the adaptability of an reliance to future changes, and reuse”. It operating system, or the form that human-machine suggests a process flow that is iterative and interaction should take. In these, and many other incremental, providing the evolutionary feel that situations, a prototyping paradigm may offer is essential in modern software development the best approach. * After Spiral Model* PHASES OF THE UNIFIED PROCESS Concurrent model - Concurrent development model (or concurrent engineering, allows a software 1. The inception phase of the UP team to represent iterative and concurrent elements encompasses both customer communication of any of the process models described in this and planning activities. By collaborating with chapter. stakeholders, business requirements for the software are identified; a rough architecture Specialized process models take on many of the for the system is proposed; and a plan for the characteristics of one or more of the traditional iterative, incremental nature of the ensuing models presented in the preceding sections. project is developed. Component-based development model 2. The elaboration phase encompasses the leads to software reuse, and reusability communication and modeling activities of provides software engineers with a number the generic process model. of measurable benefits. Your software Elaboration refines and expands the engineering team can achieve a reduction in preliminary use cases that were developed development cycle time as well as a as part of the inception phase and expands reduction in project cost if component reuse the architectural representation to include becomes part of your culture. five different views of the software—the use case model, the requirements model, the Formal methods model encompasses a set design model, the implementation model, of activities that leads to formal and the deployment model mathematical specification of computer software. Formal methods enable you to 3. The construction phase of the UP is specify, develop, and verify a computer- identical to the construction activity defined based system by applying a rigorous, for the generic software process. Using the mathematical notation. architectural model as input, the construction  When formal methods are used during phase develops or acquires the software development, they provide a mechanism components that will make each use case for eliminating many of the problems that operational for end users. To accomplish this, are difficult to overcome using other requirements and design models that were software engineering paradigms. started during the elaboration phase are  When formal methods are used during completed to reflect the final version of the design, they serve as a basis for program software increment. All necessary and verification and therefore enable you to required features and functions for the about:blank 1/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER software increment (i.e., the release) are reviewed, compiled, and tested. Metrics are then implemented in source code maintained for all important tasks and work results. 4. The transition phase of the UP 5. Postmortem. Using the measures and encompasses the latter stages of the generic metrics collected (this is a substantial construction activity and the first part of the amount of data that should be analyzed generic deployment (delivery and feedback) statistically), the effectiveness of the process activity. Software is given to end users for is determined. Measures and metrics should beta testing and user feedback reports both provide guidance for modifying the process defects and necessary changes to improve its effectiveness 5. The production phase of the UP coincides TEAM SOFTWARE PROCESS (TSP) with the deployment activity of the generic  Its goal is to build a “self directed” project team process. During this phase, the ongoing use that organizes itself to produce high-quality of the software is monitored, support for the software. operating environment (infrastructure) is  Humphrey defines the following objectives for provided, and defect reports and requests for TSP: changes are submitted and evaluated. o Build self-directed teams that plan and track PERSONAL AND TEAM PROCESS MODELS their work, establish goals, and own their  The best software process is one that is close processes and plans. These can be pure to the people who will be doing the work. If a software teams or integrated product teams software process model has been developed at a (IPTs) of 3 to about 20 engineers. corporate or organizational level, it can be o Show managers how to coach and motivate effective only if it is amenable to significant their teams and how to help them sustain adaptation to meet the needs of the project peak performance. team that is actually doing software engineering o Accelerate software process improvement by work. In an ideal setting, you would create a making CMM23 Level 5 behavior normal and process that best fits your needs, and at the expected. same time, meets the broader needs of the team o Provide improvement guidance to high- and the organization. Alternatively, the team maturity organizations. itself can create its own process, and at the o Facilitate university teaching of industrial-grade same time meet the narrower needs of team skills. individuals and the broader needs of the organization. Watts Humphrey and argues that  TSP defines the following framework activities: it is possible to create a “personal software project launch, high-level design, process” and/or a “team software process.” Both implementation, integration and test, and require hard work, training, and coordination, postmortem. Like their counterparts in PSP, but both are achievable. these activities enable the team to plan, design, and construct software in a disciplined manner PERSONAL SOFTWARE PROCESS (PSP) while at the same time quantitatively measuring  emphasizes personal measurement of both the the process and the product. The postmortem work product that is produced and the resultant sets the stage for process improvements. quality of the work product.  The PSP model defines five framework activities:  PROCESS TECHNOLOGY 1. Planning - isolates requirements and One or more of the process models discussed in develops both size and resource estimates. the preceding sections must be adapted for use All metrics are recorded on worksheets or by a software team. To accomplish this, process templates. Finally, development tasks are technology tools have been developed to help identified and a project schedule is created. software organizations analyze their current 2. High-level design. External specifications process, organize work tasks, control and for each component to be constructed are monitor progress, and manage technical quality. developed and a component design is Process technology tools allow a software created. Prototypes are built when organization to build an automated model of the uncertainty exists. All issues are recorded process framework, task sets, and umbrella and tracked. activities. The model, normally represented as a 3. High-level design review. Formal network, can then be analyzed to determine verification methods (Chapter 21) are applied typical workflow and examine alternative to uncover errors in the design. Metrics are process structures that might lead to reduced maintained for all important tasks and work development time or cost results 4. Development. The component-level design PRODUCT AND PROCESS is refined and reviewed. Code is generated, about:blank 2/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER software increment (i.e., the release) are reviewed, compiled, and tested. Metrics are then implemented in source code maintained for all important tasks and work results. 4. The transition phase of the UP 5. Postmortem. Using the measures and encompasses the latter stages of the generic metrics collected (this is a substantial construction activity and the first part of the amount of data that should be analyzed generic deployment (delivery and feedback) statistically), the effectiveness of the process activity. Software is given to end users for is determined. Measures and metrics should beta testing and user feedback reports both provide guidance for modifying the process defects and necessary changes to improve its effectiveness 5. The production phase of the UP coincides TEAM SOFTWARE PROCESS (TSP) with the deployment activity of the generic  Its goal is to build a “self directed” project team process. During this phase, the ongoing use that organizes itself to produce high-quality of the software is monitored, support for the software. operating environment (infrastructure) is  Humphrey defines the following objectives for provided, and defect reports and requests for TSP: changes are submitted and evaluated. o Build self-directed teams that plan and track PERSONAL AND TEAM PROCESS MODELS their work, establish goals, and own their  The best software process is one that is close processes and plans. These can be pure to the people who will be doing the work. If a software teams or integrated product teams software process model has been developed at a (IPTs) of 3 to about 20 engineers. corporate or organizational level, it can be o Show managers how to coach and motivate effective only if it is amenable to significant their teams and how to help them sustain adaptation to meet the needs of the project peak performance. team that is actually doing software engineering o Accelerate software process improvement by work. In an ideal setting, you would create a making CMM23 Level 5 behavior normal and process that best fits your needs, and at the expected. same time, meets the broader needs of the team o Provide improvement guidance to high- and the organization. Alternatively, the team maturity organizations. itself can create its own process, and at the o Facilitate university teaching of industrial-grade same time meet the narrower needs of team skills. individuals and the broader needs of the organization. Watts Humphrey and argues that  TSP defines the following framework activities: it is possible to create a “personal software project launch, high-level design, process” and/or a “team software process.” Both implementation, integration and test, and require hard work, training, and coordination, postmortem. Like their counterparts in PSP, but both are achievable. these activities enable the team to plan, design, and construct software in a disciplined manner PERSONAL SOFTWARE PROCESS (PSP) while at the same time quantitatively measuring  emphasizes personal measurement of both the the process and the product. The postmortem work product that is produced and the resultant sets the stage for process improvements. quality of the work product.  The PSP model defines five framework activities:  PROCESS TECHNOLOGY 1. Planning - isolates requirements and One or more of the process models discussed in develops both size and resource estimates. the preceding sections must be adapted for use All metrics are recorded on worksheets or by a software team. To accomplish this, process templates. Finally, development tasks are technology tools have been developed to help identified and a project schedule is created. software organizations analyze their current 2. High-level design. External specifications process, organize work tasks, control and for each component to be constructed are monitor progress, and manage technical quality. developed and a component design is Process technology tools allow a software created. Prototypes are built when organization to build an automated model of the uncertainty exists. All issues are recorded process framework, task sets, and umbrella and tracked. activities. The model, normally represented as a 3. High-level design review. Formal network, can then be analyzed to determine verification methods (Chapter 21) are applied typical workflow and examine alternative to uncover errors in the design. Metrics are process structures that might lead to reduced maintained for all important tasks and work development time or cost results 4. Development. The component-level design PRODUCT AND PROCESS is refined and reviewed. Code is generated, about:blank 3/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER 3. Manage -DAnalyze the probability ofWEEKS 7-8 REQUIREMENTS MODELING: FLOW, occurrence of risks at various phases. Make BEHAVIOR, AND PATTERNS plan to avoid or face risks. Attempt to minimize their side-effects. Requirements Engineering - process of 4. Monitor -DClosely monitor the potentialestablishing the services that the customer requires risks and their early symptoms. Also monitor from a system and the constraints under which it the effects of steps taken to mitigate oroperates and is developed. avoid them. Requirements - may range from a high-level 7. Project Execution & Monitoring. abstract statement of a service or of a system Activity Monitoring constraint to a detailed mathematical functional Status Reports specification. This is inevitable as requirements may Milestones Checklist serve a dual function  May be the basis for a bid for a contract - 8. Project Communication Management. therefore must be open to interpretation; Communication management process may May be the basis for the contract itself - have the following steps: therefore must be defined in detail; 1. PlanningD 3. Feedback  Both these statements may be called 2. SharingD 4. ClosureD requirements. 9. Configuration Management. Types of Requirements Change control is function of configuration User requirements - statements in natural management, which ensures that all changes language plus diagrams of the services the made to software system are consistent and system provides and its operational constraints. made as per organizational rules and Written for customers. regulations. A change in the configuration of  System requirements - structured document product goes through following steps - setting out detailed descriptions of the system’s IdentificationD functions, services and operational constraints. Validation Defines what should be implemented so may be Analysis. part of a contract between client and contractor. Control  Functional requirements - Statements of ExecutionD services the system should provide, how the Close requestD system should react to particular inputs and how the system should behave in particular PROJECT MANAGEMENT TOOLS situations. May state what the system should not 1. Gantt Chart - devised by Henry Gantt do. (1917). Represents project schedule with o Describe functionality or system services. respect to time periods. It is a horizontal bar o Depend on the type of software, expected chart with bars representing activities and users and the type of system where the time scheduled for the project activities. software is used. 2. PERT Chart - (Program Evaluation & Review o Functional user requirements may be Technique) chart is a tool that depicts project high-level statements of what the system as network diagram. It is capable of should do. graphically representing main events of o Functional system requirements should project in both parallel and consecutive way. describe the system services in detail. 3. Resource Histogram - graphical tool that  Non-functional requirements - Constraints contains bar or chart representing number of on the services or functions offered by the resources (usually skilled staff) required over system such as timing constraints, constraints time for a project event (or phase). Resource on the development process, standards, Histogram is an effective tool for staff etc.Often apply to the system as a whole rather planning and coordination. than individual features or services. 4. Critical Path Analysis - useful in  Domain requirements - Constraints on the recognizing interdependent tasks in the system from the domain of operation project. It also helps to find out the shortest path or critical path to complete the project Requirements Imprecision successfully. Like PERT diagram, each event  Problems arise when requirements are not is allotted a specific time frame. This tool precisely stated. shows dependency of event assuming an  Ambiguous requirements may be interpreted in event can proceed to next only if the different ways by developers and users. previous one is completed.  User intention – search for a patient name across all appointments in all clinics about:blank 4/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER  Developer interpretation – search for a  The system should be easy to use by medical patient name in an individual clinic. User staff and should be organized in such a way that chooses clinic then search. user errors are minimized. (Goal)  Medical staff shall be able to use all the system Requirements Completeness and Consistency functions after four hours of training. After this  In principle, requirements should be both training, the average number of errors made by complete and consistent. experienced users shall not exceed two per hour  Complet - they should include descriptions of of system use. (Testable non-functional all facilities required. requirement)  Consistent - there should be no conflicts or contradictions in the descriptions of the system Metrics for Specifying Non-Functional facilities. Requirements  In practice, it is impossible to produce a  Speed - Processed transactions/second; complete and consistent requirements User/event response time; Screen refresh time document.  Size – Mbytes; Number of ROM chips  Ease of use - Training time; Number of help Non-Functional Requirements frames  Process requirements may also be specified  Reliability - Mean time to failure; Probability of mandating a particular IDE, programming unavailability; Rate of failure occurrence; language or development method. Availability  Non-functional requirements may be more  Robustness - Time to restart after failure; critical than functional requirements. If these are Percentage of events causing failure; Probability not met, the system may be useless. of data corruption on failure  Portability - Percentage of target dependent Non-Functional Requirements Implementation statements; Number of target systems  Non-functional requirements may affect the overall architecture of a system rather than the Requirements Analysis individual components. Requirements analysis results in the  single non-functional requirement, such as a specification of software’s operational security requirement, may generate a number of characteristics related functional requirements that define It indicates software’s interface with other system services that are required. system elements, and establishes constraints It may also generate requirements that restrict that software must meet. existing requirements. The Requirements Model Non-Functional Classifications  A set of models; the first technical  Product requirements - requirements which representation of a system. specify that the delivered product must behave in a particular way e.g. execution speed, Requirements Modeling Strategies reliability, etc. 1. Structured Analysis - considers data and the  Organizational requirements - requirements processes that transform the data as separate which are a consequence of organisational entities. Data objects are modeled in a way that policies and procedures e.g. process standards defines their attributes and relationships. used, implementation requirements, etc. Processes that manipulate data objects are  External requirements - requirements which modeled in a manner that shows how they arise from factors which are external to the transform data as data objects flow through the system and its development process. system. 2. Object-oriented Analysis - focuses on the Goals and Requirements definition of classes and the manner in which  Non-functional requirements may be very they collaborate with one another to effect difficult to state precisely and imprecise customer requirements. UML and the Unified requirements may be difficult to verify. Process are predominantly object-oriented.  Goal - general intention of the user such as ease of use. The requirements modeling (or analysis modeling)  Verifiable non-functional requirement - action results in one or more of the following types statement using some measure that can be of models: objectively tested.  Scenario-based models of requirements from  Goals are helpful to developers as they convey the point of view of various system “actors”. If the intentions of the system users. you understand how end users (and other actors) want to interact with a system, your Usability Requirements software team will be better able to properly about:blank 5/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER software increment (i.e., the release) are reviewed, compiled, and tested. Metrics are then implemented in source code maintained for all important tasks and work results. 4. The transition phase of the UP 5. Postmortem. Using the measures and encompasses the latter stages of the generic metrics collected (this is a substantial construction activity and the first part of the amount of data that should be analyzed generic deployment (delivery and feedback) statistically), the effectiveness of the process activity. Software is given to end users for is determined. Measures and metrics should beta testing and user feedback reports both provide guidance for modifying the process defects and necessary changes to improve its effectiveness 5. The production phase of the UP coincides TEAM SOFTWARE PROCESS (TSP) with the deployment activity of the generic  Its goal is to build a “self directed” project team process. During this phase, the ongoing use that organizes itself to produce high-quality of the software is monitored, support for the software. operating environment (infrastructure) is  Humphrey defines the following objectives for provided, and defect reports and requests for TSP: changes are submitted and evaluated. o Build self-directed teams that plan and track PERSONAL AND TEAM PROCESS MODELS their work, establish goals, and own their  The best software process is one that is close processes and plans. These can be pure to the people who will be doing the work. If a software teams or integrated product teams software process model has been developed at a (IPTs) of 3 to about 20 engineers. corporate or organizational level, it can be o Show managers how to coach and motivate effective only if it is amenable to significant their teams and how to help them sustain adaptation to meet the needs of the project peak performance. team that is actually doing software engineering o Accelerate software process improvement by work. In an ideal setting, you would create a making CMM23 Level 5 behavior normal and process that best fits your needs, and at the expected. same time, meets the broader needs of the team o Provide improvement guidance to high- and the organization. Alternatively, the team maturity organizations. itself can create its own process, and at the o Facilitate university teaching of industrial-grade same time meet the narrower needs of team skills. individuals and the broader needs of the organization. Watts Humphrey and argues that  TSP defines the following framework activities: it is possible to create a “personal software project launch, high-level design, process” and/or a “team software process.” Both implementation, integration and test, and require hard work, training, and coordination, postmortem. Like their counterparts in PSP, but both are achievable. these activities enable the team to plan, design, and construct software in a disciplined manner PERSONAL SOFTWARE PROCESS (PSP) while at the same time quantitatively measuring  emphasizes personal measurement of both the the process and the product. The postmortem work product that is produced and the resultant sets the stage for process improvements. quality of the work product.  The PSP model defines five framework activities:  PROCESS TECHNOLOGY 1. Planning - isolates requirements and One or more of the process models discussed in develops both size and resource estimates. the preceding sections must be adapted for use All metrics are recorded on worksheets or by a software team. To accomplish this, process templates. Finally, development tasks are technology tools have been developed to help identified and a project schedule is created. software organizations analyze their current 2. High-level design. External specifications process, organize work tasks, control and for each component to be constructed are monitor progress, and manage technical quality. developed and a component design is Process technology tools allow a software created. Prototypes are built when organization to build an automated model of the uncertainty exists. All issues are recorded process framework, task sets, and umbrella and tracked. activities. The model, normally represented as a 3. High-level design review. Formal network, can then be analyzed to determine verification methods (Chapter 21) are applied typical workflow and examine alternative to uncover errors in the design. Metrics are process structures that might lead to reduced maintained for all important tasks and work development time or cost results 4. Development. The component-level design PRODUCT AND PROCESS is refined and reviewed. Code is generated, about:blank 6/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER additional, more elaborate, methods and  Systems developed incrementally will, typically, attributes need to be specified. have less detail in the requirements document. ComplexActuator: Complex actuators also  Requirements documents standards have been have the base functionality of the abstract designed e.g. IEEE standard. These are mostly Actuator class, but additional, more applicable to the requirements for large systems elaborate methods and attributes need to be engineering projects. specified. The Structure of a Requirements Document Collaborations - describes how objects and classes  Preface - should define the expected readership interact with one another and how each carries out of the document and describe its version history, its responsibilities. including a rationale for the creation of a new version and a summary of the changes made in FaultHandler - a class that contains methods for each version. handling error messages, such as starting a more  Introduction - should describe the need for the elaborate recovery mechanism or a backup device. system. It should briefly describe the system’s functions and explain how it will work with other ActiveSensors offer methods to add or remove the systems. It should also describe how the system addresses or address ranges of the components that fits into the overall business or strategic want to receive the messages in case of a value objectives of the organization commissioning the change. software.  Glossary - should define the technical terms Metrics for Requirements Model used in the document. You should not make Software requirements document - official assumptions about the experience or expertise of statement of what is required of the system the reader. developers. Should include both a definition of user  User requirements definition - describe the requirements and a specification of the system services provided for the user. The nonfunctional requirements. It is NOT a design document. As far as system requirements should also be described in possible, it should set of WHAT the system should do this section. This description may use natural rather than HOW it should do it. language, diagrams, or other notations that are Agile Methods and Requirements understandable to customers. Product and  Many agile methods argue that producing a process standards that must be followed should requirements document is a waste of time as be specified. requirements change so quickly.  System architecture - should present a high-  The document is therefore always out of date. level overview of the anticipated system  Methods such as XP use incremental architecture, showing the distribution of functions requirements engineering and express across system modules. Architectural requirements as ‘user stories’. components that are reused should be  This is practical for business systems but highlighted. problematic for systems that require a lot of pre- delivery analysis (e.g. critical systems) or  System requirements specification - should systems developed by several teams. describe the functional and nonfunctional requirements in more detail. If necessary, further Users of a requirements document detail may also be added to the nonfunctional  System customers - specify the requirements requirements. Interfaces to other systems may be and read them to check that they meet their defined. needs. Customers specify changes to the  requirements.  System models - might include graphical  Managers - use the requirements document to system models showing the relationships plan a bid for the system and to plan the system between the system components and the system development process and its environment. Examples of possible  System engineers – use the requirements to models are object models, data-flow models, or understand what system is to be developed. semantic data models.  System test engineers – use the requirements  System evolution - should describe the to develop validation tests for the system. fundamental assumptions on which the system is  System maintenance engineers - use the based, and any anticipated changes due to requirements to understand the system and the hardware evolution, changing user needs, and so relationships between its parts. on. This section is useful for system designers as it may help them avoid design decisions that Requirements Document Variability would constrain likely future changes to the  Information in requirements document depends system. on type of system and the approach to  Appendices - should provide detailed, specific development used. information that is related to the application about:blank 7/8 11/11/24, 10:39 PM SE101 - Summary Software Engineering 1 SE101 – SOFTWARE ENGINEERING MIDTERM REVIEWER being developed; for example, hardware and define the functional requirements for the database descriptions. Hardware requirements system; UML use case and sequence diagrams define the minimal and optimal configurations for are commonly used. the system. Database requirements define the  Mathematical specifications - These notations logical organization of the data used by the are based on mathematical concepts such as system and the relationships between data. finite-state machines or sets. Although these  Index - Several indexes to the document may be unambiguous specifications can reduce the included. As well as a normal alphabetic index, ambiguity in a requirements document, most there may be an index of diagrams, an index of customers don’t understand a formal functions, and so on. specification. They cannot check that it represents what they want and are reluctant to Requirements Specification accept it as a system contract  The process of writing don the user and system requirements in a requirements document. Guidelines for Writing Requirements  User requirements have to be understandable by  Invent a standard format and use it for all end-users and customers who do not have a requirements. technical background.  Use language in a consistent way. Use shall for  System requirements are more detailed mandatory requirements, should for desirable requirements and may include more technical requirements. information.  Use text highlighting to identify key parts of the  The requirements may be part of a contract for requirement. the system development.  Avoid the use of computer jargon.  Include an explanation (rationale) of why a requirement is necessary. Ways of Writing a System Requirements Specification  Natural language - The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.  Structured natural language - The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.  Design description languages - This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.  Graphical notations - Graphical models, supplemented by text annotations, are used to about:blank 8/8