1 CEN 4020 Software Engineering PPT2: Software process modeling Software process A Process is a series of steps involving activities, constraints and resources that produce an intended output. More simply a process is a set of ordered tasks. In the process of building a house, the house must be wired before the drywall goes up. The order of events is important to the success of the process. 2 Characteristics of a process Prescribes all major process activities (Defined on next slide). Uses resources with constraints (for example a schedule) that produce an intermediate or final output. Can be a hierarchy of sub-processes linked together that have their own process models. Has entry and exit criteria so we know when it begins and ends. Activities are organized in a sequence. Every process has a set of guideline principles explaining the goals of each activity. Constraints or controls may apply to an activity, resource or product. For example the length of time an activity can take. 3 Major activities The stages of software development are processes which are a set of activities. These stages are as follows: Requirements analysis and definition System design Program design Program implementation Unit testing Integration testing System testing System delivery Maintenance 4 Software process models A software model can be either: A) Prescriptions of the way software development should progress. OR B) Descriptions of the way software development is actually done. The two models should be very similar theoretically but in practice they are not. 5 Reasons for modeling Building process models and explaining the sub-processes gives a team an understanding of what needs to be done compared to what has already been done. Develops a common understanding of activities, resources and constraints involved in the software development. Helps to find inconsistences, redundancies and omissions (whats missing) in the process, which can then be noted and corrected. Reflects the goals of development for example finding faults early, budget and schedule constraints etc. The team can evaluate potential activities for things like meeting requirements BEFORE the design begins. Understanding the special situations for which a process needs to be tailored toward and where in the process that tailoring occurs. 6 The Waterfall Model The Waterfall Model is sequential. Each stage must be completed and documented before the next begins. Pros: o Simple for customers to understand. o Helps developers lay out what needs to be done. o Points out intermediate products are necessary for the next stage of development. Cons: o Doesnt account for changes in products and activities likely to occur. o Doesnt reflect the way the code is developed. o In general, your likely to run into problems that require you to backtrack after solving them. 7 Software development in reality Developers have to experiment with things to figure out how to address new problems. Consequently they end up going back and forth between the development stages. Therefore in reality the software process looks more like this 8 Waterfall model with prototyping Prototyping is a sub-process that uses prototypes. A prototype is an unfinished product that is made to decide if an aspect of the process is sufficient for the finished product. For example user-Interfaces are often built and tested as a prototype so developers can see how users like to interact with the system. Validation is the process of ensuring all the requirements are met by the system. (Did we build the right product?) Verification is the process of ensuring that all the functions operate correctly. (Did we build a quality product?) Notice in figure 2.3 that validation and verification often lead to changes in the requirements analysis and system design, hence prototyping is useful in such stages. 9 The V-model The V-model is much like the waterfall model except that it shows how testing stages relate to the analysis and design stages. First the execution stages are performed, then the code is written, then testing methods are used to check if any re-execution is needed. Unit & integration testing addresses the program correctness but can also be used to verify the program design. System testing is for verifying the correctness of the system design. Acceptance testing (done by the customer) is for validation that the requirements have been met. 10 Execute Write Check The prototyping model Prototyping reduces risk and uncertainty in development. Prototypes of only part of the system can be built quickly. That part of the system can then be tested and revised or compared to other prototypes for that part of the system to ensure the best possible option is perfected and used. Customers and users are used for validation of these prototypes. 11 The figure below is the prototyping model by itself. Notice that because the stages are related/hierarchal, the revisions can transfer over to the list of revisions for the previous/higher level stages. Also the prototype requirements are sometimes only part of the system and informal to save time. Operational specification model The operational specification model allows customers and developers to examine the requirements and their implications early in development. Requirements are enacted using a software package that demonstrates the behavior of the system. This way the implications of the requirements can be assessed before design begins. As the figure to the right shows: The operational specification stage merges the functionality and design which can help the customer and developer define the requirements exactly, by example, before any actual implementation. Once the requirements are defined exactly, the design can then be implemented. This is called the transformed specification stage. Aside from all that, this is very similar to the prototyping model. 12 Execute and Revise Operational Specification (problem- oriented) Transformed Specification (implementat ion-oriented) TEST System Requirements (sometimes informal or incomplete) Delivered System The transformational model The transformational model tries to eliminate development steps to reduce the risk for errors. Such methods include: Changing data representations Selecting algorithms Optimizing Compiling A set of formal specifications can be used to enable transformations into a deliverable system. Each transformation is recorded along with the rationality behind them. As shown in the diagram, formal specifications are written and compared to the requirements, then changed as needed. The formal specifications are then transformed into executable statements and recorded. 13 Phased development model The phased development model allows users to use some portion of a system while it is still being developed. The development systems are the next release to replace the one currently in production. The production systems are the ones currently being used by the user. Often times they will number different releases (Ex. version 2.0) 14 Incremental and iterative models Two ways to organize the releases (from the last slide) are Incremental and Iterative development. In incremental development, the system is partitioned into subsystems according to functionality. Functionality is then added by adding subsystems in future releases. In iterative development, the whole system is released right off the bat, though the subsystems are incomplete. The subsystems are then changed for the better/completed in future releases. 15 Incremental and iterative models (continued) The combination of incremental and iterative models is often used in the real world. In other words when new subsystems are added old subsystems may also be enhanced. This is important for several reasons: 1. Training can start at the beginning. Developers can observe training sessions and make adjustments or enhancements. 2. Markets can be created for newly introduced functionality early on. 3. Unanticipated problems can be fixed quickly for new releases because they are reported from the previous systems. 4. Different areas of expertise can be focused on for different released. For example a system that uses command line arguments can be updated to a GUI in a new version. 16 The spiral model The spiral model aims to add risk management in with the development process. The model is divided into four stages: 1.) Plan (budget, constraints, staff etc.) 2.) Determine goals, alternatives and constraints 3.) Evaluate alternatives and risks (includes prototypes) 4.) Develop and test (as in other models) These steps progress repeatedly in an iterative fashion. 17 The spiral model in the figure below starts here in the determining goals, alternatives and constraints stage. Once a budget for the first iteration is established alternatives and constraints are determined. Then the risk is analyzed and based on this a prototype is built for the concept of operation, then a life-cycle plan is determined based on requirements. As the development continues along the spiral, notice how the budget and constraints are determined, risk is analyzed and a prototype is built for each iteration/cycle. Agile methods An alternative way to thinking about software development has evolved into four principles known as the Agile Manifesto: 1)Value individuals and interactions over processes and tools. In other words give the developers the needed resources and trust them to do their jobs. 2)For time investment, focus on producing software rather than documentation. 3)For customer interaction, focus on collaboration rather than contract negotiation. 4)For planning, focus on responding to change rather than making a set plan to follow. 18 Agile methods (continued) Some examples of agile processes that use the agile manifesto: Extreme programming (XP): A set of techniques that promote the creativity of the developer and minimize administrative overhead (more on this coming soon). Crystal: A collection of approaches based on the idea that different projects need different policies, conventions, and methodologies. The creator believes that better people, communication, and frequent delivery leads to better development. Scrum: Scrum uses iterative development with a 30-day iteration called a sprint to implement prioritized requirements. Multiple teams develop implementations in parallel. Coordination of this is done with a daily meeting called a scrum. Adaptive software development (ASD): ASD includes six principles. (See next slide) 19 Six principles of Adaptive Software Development (ASD): 1)Theres a mission. Destinations act as a guideline, with no prescription on how to get there. 2)Projects are organized around building components to provide features as that is what the customer wants. 3)Iteration is important, so redoing is just as important as doing. 4)Change is embraced and viewed as an adjustment not a correction. 5)Requirements are scoped down for versions to meet deadlines. 6)Risk is embraced so the hardest problems are solved first. 20 The 12 facets of extreme programming (XP): 1)The planning game: Each requirement is assessed/graded in terms of value by the customer for prioritization purposes. 2)Small releases: Designed so functionality can be delivered ASAP and expanded in later versions. 3)Metaphor: Agreements on common names for things and how the system will operate. 4)Simple design: Only current needs are addressed to avoid unnecessary functionality. 5)Writing tests first: Functional test cases and unit test cases are written first to force the customer to deliver testable requirements. 6)Refactoring: Revisiting the requirements and design to match both new and existing needs as changes may occur. 21 The 12 facets of extreme programming (XP) (continued): 7)Pair programming: Two (or more) developers are given a task. This can promote the mix of the artistic and scientific side of programming as well as teach novice programmers by pairing them with experienced programmers. 8)Collective ownership: Any developer can make a change to any part of the system. 9)Continuous integration: Working systems are promised to the customer daily or sometimes hourly to view small improvements. 10)Sustainable Pace: Fatigue causes errors, aim for 40 hour work weeks. 11)On-site customer: Customers should be on-site to provide feedback. 12)Coding standards: The goal is to have an end result of a code that looks like it was written by one person. A standard is provided in order to do so. 22 Tools for process modeling Notation: The notation you use depends on what you want to capture in your model. Textual notation can be used to express processes as functions. Graphical notation expresses processes as a hierarchy of boxes and arrows or pictures and text that link to tables and functions. Many notations can be used for representing requirements. Two types of models: A static model shows how the inputs are transformed in to outputs. A dynamic model enacts the process, showing how intermediate and final products transform over time. 23 Static modeling A comprehensive process notation that allows anyone to model a process at any level of detail was developed by Lai in the early 90s. The elements of a process are viewed as seven different types in Lai notation: 1)Activity: Something that will happen. Includes what triggers it, what resources it needs, what rules it follows, how to describe the algorithms and lessons learned. 2)Sequence: The order of activities. Described using triggers, constructs, transformations, ordering or satisfaction of conditions. 3)Process model: Interests about the system. Some parts may need to be modeled separately if it is a process on its own. This helps to predict process behavior or look at characteristics. 24 Static modeling (continued) 4)Resource: An item, tool or person needed. Includes equipment time, office space, people techniques etc. 5)Control: An external influence on a process. Can be manual or automatic, human or machine. 6)Policy: Guiding principle. Essentially a constraint. May include a prescribed development process, a tool that must be used, or a mandatory management style. 7)Organization: Hierarchal structure of process agents. Mapping from physical grouping to logical grouping. Should be able to reflect changes in physical environment. The process description has many levels of abstraction. Lais notation uses several templates including the Artifact Definition Template which records information about artifacts. 25 Lai notation example 26 The figure to the right is an example of Lai notation. It is a picture that includes text that link to a table that is the artifact a Car. The table includes states (parked, initiated, moving) and sub- artifacts ( doors, engine etc.) among other information that can all be mapped to from this diagram. Lai notation example (continued) A transition diagram can also be used to describe how the car can transition between the three states parked, initiated and moving. This look much like any other state diagram except words are used for example Go represents the signal that transitions from initiated to moving. 27 Dynamic modeling In dynamic modeling the goal is to enact the process and watch what happens to the resources and artifacts as the activities occur. The figure to the right is Abdel- Hamids understanding of how factors affect productivity. The arrows represent how changes in one factor affects another. 28 Dynamic modeling (continued) The figure to the right is Abdul-Hamids structure of software development model from He defined four categories of things that affect productivity: Software production, human resource management, planning and control. This technique is particularly helpful when dealing with large systems with many causal links. 29 Practical process modeling In 1995 a case study was performed by Barghouti, Rosenblum, Belanger, and Alliegro. The study was to determine the feasibility, utility, and limitations of process models used in large organizations. Both studies used Marvel Specification Language (MSL) which aims to produce a three part process with three main constructs: 1)A rule-based specification of process behavior 2)An object-oriented definition of the models information process 3)A set of envelopes to interface between Marvel and external software tools used for process execution. In particular the study was of an AT&T call-processing network. Three work centers were responsible for routing calls and handling errors. Work center 1 monitored the network and notified the other 2 work centers of any faults or failures. Work center 2 handled software and human faults that required analysis. Work center 3 handled hardware failures. 30 Practical process modeling (continued) The diagram to the right shows the process monitored in the study. Double dashed lines show which process uses a tool or database. The ovals represent a tool or database. The rectangles represent activities or tasks. The diamonds represent decisions. The arrows represent the flow of control. 31 Practical process modeling (continued) The figure to the right is the code written for the study in Marvel Specification Language (MSL). The upper half is the definition of the class representing a trouble ticket. A trouble ticket is fault report from work center 1 in this case. The lower half is a rule for how a trouble ticket is diagnosed. It would correspond to the rectangle on the last slide labeled Diagnose. 32 References Hindsight is 20/20: Lexmark's advice to future engineers - Lexmark News Blog. (2015). Retrieved January 26, 2016, fromfuture-engineers/ Pfleeger, S. L., & Atlee, J. M. (2010). Software Engineering Theory and Practice (4th ed.). Upper Saddle River, NJ: Pearson Higher Education. Strasser, K., & Arevalo, M. (n.d.). Retrieved January 26, 2016, fromwiring.htm 33