Download
1 / 73
730 likes | 742 Views
SEC 308 Yazılım Mühendisliği Software Process Models. A Layered Technology. tools. methods. process model. a “quality” focus. Software Engineering. Definition. Process Defines who is doing what, when, and how to reach a certain goal.
E N D
A Layered Technology tools methods process model a “quality” focus Software Engineering
Definition • Process • Defines who is doing what, when, and how to reach a certain goal. • Forms the basis for management control of software projects. • Methods • technical “how to” for building software • Broad array of tasks: communication, requirements analysis, design modeling, program construction, testing, and support • Tools • Automated support for process and methods
A Process Model • A structured set of activities required to develop a software system • Prescribe a set of process elements • Framework activities • Software engineering actions • Tasks • Work products • Quality assurance and • Change control mechanisms for each project • Each process model also prescribes a workflow
Plan-driven and agile processes • Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. • In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. • In practice, most practical processes include elements of both plan-driven and agile approaches. • There are no right or wrong software processes
A Process Framework Software Process • Process framework • Modeling activity • Software Engineering action: Analysis • work tasks: requirements gathering, • elaboration, negotiation, • specification, validation • work products: analysis model • and/or requirements spec • milestones & deliverables • QA checkpoints • Software Engineering action: Design • work tasks: data design, architectural, interface design, • component design • work products: design model • and/or design specification • … • Umbrella Activities Process framework • Framework activity 1 • work tasks • work products • milestones & deliverables • QA checkpoints Framework activity n Umbrella Activities
Process Flow Executes each of the framework activities in sequence, beginning with communication and culminating with deployment Repeats one or more of the activities before proceeding to the next
Process Flow (cont.) Executes the activities in a “circular” manner, each circuit through the five activities leading to a more complete version of the software Executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software in parallel with construction of another aspect of the software
Key Question • What actions are appropriate for a framework activity, • given the nature of the problem to be solved, • the characteristics of the people doing the work, and • the stakeholders who are sponsoring the project? • Different project demand different task sets • Software team chooses the task set based on • Problem and project characteristics • Characteristics of the project team
Example I • For a small, relatively simple project, task set for requirements gathering • Make a list of stakeholders for the project • Invite all stakeholders to an informal meeting • Ask each stakeholder to make a list of features and functions required • Discuss requirements and build a final list • Prioritize requirement • Note areas of uncertainty
Example II • For a larger, more complex software project, • Make a list of stakeholders for the project • Interview each stakeholder separately to determine overall wants and needs • Build a preliminary list of functions and features based on stakeholder input • Schedule a series of facilitated application specification meetings • Conduct meetings • Produce informal user scenarios as part of each meeting • Refine user scenarios based on stakeholder feedback • Build a revised list of stakeholder requirements • Use quality function deployment techniques to prioritize requirements • Package requirements so that they can be delivered incrementally • Note constraints and restrictions that will be placed on the system • Discuss methods for validating the system
Build & Fix Model • Product is constructed withoutspecifications or any attempt atdesign • Ad-hoc approach and not well-defined • Simple two phase model
Build & Fix Model - Drawbacks • Suitable for small programming exercises of 100 or 200 lines • Unsatisfactory for software for any reasonable size • Code soon becomes unfixable & not enhanceable • No room for structured design • Maintenance is practically not possible
The Waterfall Model(Classic Life Cycle) • Suggests a systematic, sequential approach to software development • It reinforcesthe notion of “define before design” and “designbefore code”. • Works best when • Requirements of a problem are reasonably well understood • Well-defined adaptations or enhancements to an existing system must be made • Requirements are well-defined and reasonably stable
TheWaterfall Model - Drawbacks • It is difficult to define all requirements at the beginning of aproject • This model is not suitable for accommodating any change • A working version of the system is not seen until late inthe project’s life • It does not scale up well to large projects. • Real projects are rarely sequential.
The Incremental Model • It combines elements of the waterfall model applied in an iterative fashion • It delivers a series of releases, called increments, that provide progressively more functionality for customer as each increment is delivered • When it is used, the first increment is often a core product; basic requirements are addressed, but many supplementary features remain undelivered • The core product is used by customer. As a result, a plan is developed for next increment
TheIncremental Model • This model focuses on the delivery of an operational product with each increment • Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people, and additional staff can be added to later increments • Increments can be planned to manage technical risks
TheRAD Model • RAD (Rapid Application Development) is an incremental SW process model that emphasizes a short development cycle • RAD model is a “high-speed” adaptation of the waterfall model, achieved by using a component-based construction approach • If a business application modularized in a way that enables each major function to be completed in less than 3 months, it is a candidate for RAD
The RADModel • Build a rapid prototype • Give it to user for evaluation & obtainfeedback • Prototype is refined with active participation of users
The RADModel - Drawbacks • Not an appropriate model in the absence of userparticipation. • For large, but scalable projects, RAD requires sufficient human resources to create right number of RAD teams • Highly specialized & skilled developers are not easily available. • If a system cannot be properly modularized, building the components necessary or RAD will be problematic • Reusable components are required to reduce developmenttime. • RAD may not be appropriate when technical risks are high
Evolutionary Process Models • Evolutionary models are iterative • They are characterized in a manner that enables SW engineers to develop increasingly more complete versions of the software • Example models • Prototyping model • The Spiral model • Concurrent model
Evolutionary Models: Prototyping • The prototype may be a usable program but is not suitable asthe final software product. • The code for the prototype is thrown away. However, experience gathered helps in developing the actual system. • The development of a prototype might involve extra cost, butoverall cost might turnout to be lower than that of anequivalent system developed using the waterfall model.
Evolutionary Models: Prototyping - Drawbacks • The customer sees what appears to be a working version of SW, unaware that in the rush to get it working we haven’t considered overall quality or long-term maintainability • The developer often makes implementation compromises in order to get prototype working quickly
Evolutionary Models: Spiral • Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model • Provides the potential for rapid development of increasingly more complete versions of the software • A risk-driven process model generator • It has two main distinguishing features • Cyclic approach - Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk • A set of anchor point milestones - A combination of work products and conditions that are attained along the path of the spiral
Evolutionary Models: Spiral • Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software • The circuits around the spiral might represent • Concept development project • New Product development project • Product enhancement project • The spiral model demands a direct consideration of technical risks at all stages of the project
Evolutionary Models: Spiral - Drawbacks • Difficult to convince customers that evolutionary approach is controllable • Demands considerable risk assessment expertise and relies on this expertise for success • If major risks are uncovered and managed, problems will occur
Evolutionary Models: Concurrent • Sometimes called concurrent engineering • Can be represented schematically as a series of framework activities, software engineering actions and tasks, and their associated states • Defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks • Defines a network of activities • E. g. The modeling activity which existed in none state while initial communication was completed, now makes a transition into under development state. If customer indicates that changes in requirements must be made, modeling activity moves from under development state into awaiting changes state
Evolutionary Models: Concurrent • Is applicable to all types of software development and provides an accurate picture of the current state of project • All activities exist concurrently but reside in different states • Events generated at one point in the process network trigger transitions among the states
Other Process Models • Component-based development—theprocess to apply when reuse is a development objective • Formal methods—emphasizes the mathematical specification of requirements • AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects • Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
The Unified Process (UP) • It is a use-case driven, architecture-centric, iterative and incremental software process • UP is an attempt to draw on the best features and characteristics of conventional s/w process models • Also implements many of the best principles of agile software development • UP is a framework for object-oriented software engineering using UML (Unified Modeling Language)
Phases of UP - Inception • Defines scope of the project • Encompasses both customer communication and planning activities • Fundamental business requirements are described through a set of preliminary use-cases • A use-case describes a sequence of actions that are performed by an actor (e.g., a person, a machine, another system) as the actor interacts with the software • A rough architecture for the system is also proposed
Phases of UP - Elaboration • Encompasses customer communication and modeling activities • Refines and expands the preliminary use-cases • Expands the architectural representation to include five different views of the software • The use-case model • The analysis model • The design model • The implementation model • The deployment model • In some cases, elaboration creates an “executable architectural baseline” that represents a “first cut” executable system
Phases of UP - Construction • Makes each use-case operational for end-users • As components are being implemented, unit tests are designed and executed for each • Integration activities (component assembly and integration testing) are conducted • Use-cases are used to derive a suite of acceptance tests
Phases of UP - Transition • Involves many activities like delivering, training,supporting, and maintaining the product. • Software is given to end-users for beta testing • The software team creates the necessary support information • User manuals • Trouble-shooting guides • Installation procedures • At the conclusion of the transition phase, the software increment becomes a usable software release
Phases of UP - Production • Coincides with the deployment activity of the generic process • The on-going use of the software is monitored • Support for the operating environment (infrastructure) is provided • Defect reports and requests for changes are submitted and evaluated
Unified ProcessWork Products • Inception • Vision document • Initial use-case model • Elaboration • Analysis model, design model • Construction • Implementation model, deployment model, test model • Transition • Delivered software, beta test reports, general user feedback
Selection of a Process Model Selection of a model is based on: • Requirements • Development team • Users • Project type and associated risk
