Process Models: Perspective Process Models Lecture # 4Objectives ™ The objectives of this lecture Is to © Understand the concept of sofware processes = Unc sland the generic framework activities tr present in every proc = Understand how the processes are modelled and what are process patterns = Understand perspective process models and their strength and weaknesses[ie NED QZ Software Process = A process Is a collection of activities, actions and tasks that are performed, when some work product is to be created. = It Is a adaptable approach that enables people to pick and choose appropriate set of work actions and tasks.(e:NED@S Generic Process Framework Activities fF t * Involves communication among the customer and other Lf stake holders, encompasses requirement gathering + Establishes a plan for software engineering work, address technical tasks, resources, work products and work schedule + Encompasses the creation of models to better understand the requirements and designs + Combines code generation and testing to uncover = 7 L errors + Involves delivery of software to the customer for evolution and feedback= Process Framework Activities = Work tasks = Work products = Milestones and deliverables = Q&A checkpoints = Umbrella Activities (e:NED@@ Software Process Framework[ie NED GZ) Software Process Framework = Defining a Framework Activity © What actions are appropriate for a f ework activity, given © the nature of the problem to be solved, = the charac le doing the we © and the stai[ie NED GZ) Software Process Framework = Identifying a Task set 1e actual work to be done to accomplish the objectives of a Ist of the = Alistof t applied based on prob[ie NED GZ) Software Process Framework = Process pattern @ processtelated problem that is encountered during software > general term .attem provides yo meth[NED GS Software Process Framework = Process Pattern Types = Stage patterns process fines a problem associated with a framework activity for the d with a software or work task and relevant to successful sofware v. = Pha proc: © Task patterns—defines a problem ass engineering action gineering practice define the sequence of framework activities that oc when the overall flow of activities is iterative in nature. with the pat ™ Once process pattems have been developed, they can be reused for the definition of process variants> NED GI] Software Process Framework Proposed Process Pattern Template | = Pattern Name: The pattern is given a meaningful name describing it within the context of the software process (e.g., TechnicalReviews). = Forces: The environment in which the pattern is encountered and y the issues that make the problem visible and may affect its /. solution. = Type: The pattern type is specified. ® Initial context: Describes the conditions under which the pattern applies.[oe NED G9) Software Process Framework Proposed Process Pattern Template = Problem: The specific problem to be solved by the pattern ® Solution: Describes how to implement the pattern successfully. = Resulting Context: Describes the conditions that will result once the pattem has been successfully implemented. vy ™ Related Patterns: Provide a list of all process patterns that are directly related to this one. = Known Uses and Examples: Indicate the specific instances in which the pattern is applicable.NED G9) Software Process Framework Proposed Process Pattern TemplateNEDG@Q? Process Flow — poe Planning / Modeling He} Deployment + (0} Linear process flow Fema Planning Construction Modeling Deployment [i (b erative proces fwProcess Flow Tine —> cnc (ef Evoonary proces How [Perle process flow[eoNED GZ How do process models differ from one another? I flow of activities, actions, and tasks and the interdependencies among 2e to which actions and tasks are defined within each framework activity Degree to which work products are identified and required Manner in which quality assurance activities are applied Manner in which project tracking and control activities are applied Overall deg De project 2¢ of detail and rigor with which the process is described s euuees to which the customer and other stakeholders are involved with the Level of autonomy given to the software team: Degree to whic! team organization and roles are pr