1 Development models R. Kuiper and E.J. Luit 1 Introduction We reconsider the classical development models: the Waterfall Model [Bo76], the V-Model [Ro86], the Spiral Model [Bo88], together with the further assessment of the Spiral Model in [Bo96], and the Rational Unified Process [JBR99, Kr00]. All these models concern grouping of development activities and the flows of information and time. Two observations are made. Firstly, time and information flow in these models are not always well separated. This is unfortunate, as these flows sometimes do and sometimes do not coincide and it is often important to know explicitly whether time or information flow is intended. Secondly, development activities are grouped together in various ways that are not always explicitly motivated. This is unfortunate, because it means the aim of certain groupings is not clear. This analysis results in two proposals. Firstly, we separate the information flow and the time ordering. Secondly, we explicitly and systematically argue the grouping of activities. Although many activities and information flows are common to different development processes, there are also many differences, depending on the context. For example, hardware-software co-development requires additional activities over pure software development. Therefore, we define a development framework and give an example of a possible choice of activities and information flows. Likewise, we do not suggest a particular process, as this again depends on the context. Certain projects can be done best in a waterfall-like manner, whereas an iterative approach is more suited to others. For example, for a small project in a well-known domain, a waterfall-like process may be most appropriate, whereas an iterative process may be more appropriate for a large project. We order activities in a V, following the traditional V models. This ordering represents only information dependencies between the activities. The left leg of the V corresponds to decomposition activities, whereas the right leg corresponds to composition activities. The V shape is convenient because this way, the flow of information between the legs of the V can be depicted concisely. We introduce several Vs to accommodate different roles so that information flows and dependencies between different roles can be explicitly visualized. The timing is treated separately, as are various kinds of process, e.g., top-down or bottom-up. Sequencing of activities is more conveniently visualized with, e.g., Gantt-charts. To use this framework of Vs, the appropriate activities and their groupings must be selected first. Then, it must be considered which information flows and artifacts are needed. Finally, the time sequencing of different activities must be selected, i.e., the process must be defined. 2 Analyzing development models Considering the classical development models, the most established are the Waterfall Model, the V-Model, the Spiral Model and the RUP.
2 2.1 The Waterfall Model Figure 1 Boehm's waterfall model The Waterfall Model, [Bo76], provides the following information. 1. The development phases in the software life cycle are ordered in time: a linear ordering of, roughly, requirements analysis, design, coding, testing and maintenance; these are depicted as boxes. Boehm actually uses slightly different terminology. We use verbs to name these phases, which indicates that activities are associated with the boxes. Transitions from one phase to another are drawn as arrows; the arrows express information flow and time ordering. 2. Validation occurs in each phase: the output of a development phase is validated against the input of that phase. In the Waterfall Model, validation is included as a box at the bottom of the phasebox. This suggests that validation occurs at the end of the activities in a box. 3. As later phases might lead to reconsidering earlier ones, there are feedback arrows. Boxes identify a development phase and arrows indicate the time order. Implicitly, there is also information flow between phases: activities in a phase use information from the previous phase. A problem is that because of the feedback arrows, the time order and the information flow are quite complex. Especially for validation activities, neither the timing nor the information flow is very detailed or explicit. This suggests a first idea, namely to separate time and information flow.
3 2.2 The V Model Figure 2 Rook's V-Model The V-Model, [Ro86], again uses boxes to depict development phases. In addition, the main deliverables of the characteristic activities of the phases are depicted by ovals in between the boxes. Rook emphasizes that no strict time flow is intended by the arrows and that, in fact, iterations between the activities are common practice. The V-Model recognizes that testing consists of various kinds of testing, like module and integration testing, and that information used stems not only from the coding phase, but also from earlier development phases. To indicate this information flow, the V-model folds at the coding phase, thus bringing the corresponding phases opposite one another. Arrows indicate the relations between the deliverables on both sides of the V. In fact, this is the information flow from the development activities to the corresponding test activities. In later Figure 3 Other representation of the V-Model versions of the V-Model , the deliverables are often left out as shown in figure 3. Again, the arrows show the (time and?) information flow from the development activities to the corresponding test activities. The additional detail that the V-Model provides shows a problem. Even though Rook depicts the main deliverables, most other V-Models do not. It is not clear what the artifacts used and produced in the various phases are; are these test specifications, test implementations, executions of tests against implementations, test outcomes? In one V, it is difficult to accommodate all the artifacts. A solution to this problem is indicated by various attempts to split the V into several Vs. Activities that have a similar nature are grouped together in a separate V. Also V-Models with sub-models have been developed, an example is [IABG95]. Cockburn [Co95, Co97] groups management activities into a separate V. This leads to the second idea: group activities not only into Vs but also split these Vs into multiple Vs.
4 Other problems are that the V-Model suggests that the activities are executed sequentially and that no testing activities take place in early stages of a project. Even though a sequential execution of the activities was not intended by the original V-Model, it is often interpreted this way. In fact, Rook presents a figure with estimated effort for different development teams that is very similar to figures used in RUP publications. This leads to another idea, namely to provide an explicit and different representation of the sequencing of activities. Also, with a separate Test-V, the possibility for early testing activities can be made explicit. 2.3 The Spiral Model Figure 4 The Spiral Model The Spiral Model [Bo88], addresses the problem that both Waterfall and V-Model suffer from an unrealistic modeling of timing of phases. It recognizes that development is often iterative and graphically depicts this by providing multiple instances of the phases from these models and ordering these as a spiral. Thus, a more realistic representation of timing is provided. The spiral model can then be viewed as one of the possible timing models for the Waterfall Model. The drawback of detailing time is that now the complexity of the mix of information and time flow becomes even larger than before: information flow arrows would be duplicated wherever phase duplication occurs because of the time detailing. 2.4 The Rational Unified Process (RUP) RUP groups activities by defining the following workflows: Business Modeling, Analysis and Design, Implementation, Testing, Deployment, Configuration and Change Management, Project Management and Environment. Workflows are similar to (a group of) boxes in the V-Model. RUP
5 explicitly does not impose an ordering in time of the workflows. RUP places activities in the workflows but does not group activities together like in the boxes of the Waterfall and V-Models. This we consider an omission, as this level of abstraction is in fact the most relevant to depict artifact stability and information flow. In RUP, the dependencies between activities of a workflow are visualized with a kind of Activity Diagrams... The timing or process part is described separately in RUP; timing is given as steps: one step is a full iteration through all workflows. The time order of the workflows is not indicated, but the amount of time spend on the workflows per iteration is described. Time order is indicated between activities. The iterations are grouped in phases: Inception, Elaboration, Construction and Transition. (Further detail is, that RUP may use different perspectives on the workflows, e.g., Technical and Managerial; the perspectives synchronize on deliverables. The synchronization is more driven by the availability of the results from the two perspectives than by timing; i.e., the information flow rather than the time flow is decisive. Deliverables are Conceptual Prototype, Architectural Prototype, Architectural Baseline, Releases and Deliveries.) One traversal of these phases, a cycle, produces one software generation. A new traversal of the cycle produces a new generation (in RUP this, somewhat confusingly, is also called a phase: Evolution). 2.5 Conclusions from the analysis and some new ideas Idea 1: Separate time and information flow. Therefore, define an information flow model and, for this model, a timing (process) model. Idea 2: Use activities as basic ingredients, group these into Tasks, partly driven by what belongs together by nature (groups of workers, development of one kind of object, what allows best picturing of information flow,...). Idea 3: Use Vs to order groups of activities to represent information flow. Our motivation for the V-shape is, that an important (information flow rather than timing) ordering on the workflows (in the various perspectives) is, whether the activity is decompositional or compositional in nature. Corresponding decomposition/composition steps need information transfer; this is easy to depict when they are at opposite positions in the V. Note, that the Vs are quite close to the RUP workflows but that we consider the construction activities to belong together and therefore group them into a Realization V. Furthermore, there are some ideas from other approaches that we want to employ. To make explicit what is used and produced in these activities, input and output artifacts are defined for each phase. These come both form previous phases as well as from the outside. The latter in, at least, two flavors: extra detail like design decisions and extra constraints that do not follow from previous phases but are fixed environment constraints. An example of the first is
6 deciding to use a certain design pattern, an example of the second is to use a certain platform because it is the company standard. Evidently, the two may influence one another. As to timing (process), we observe that to provide assessment points during development, anchor points are used: in [Bo96] anchor points for evaluation are defined that occur at the unfolding spiral. These anchor points are not located at fixed points of each cycle but are milestones in the full lifecycle: life-cycle objectives, life-cycle architecture and initial operational capability. RUP employs a similar device in grouping iterations (comparable to one traversal in a spiral model) into phases. The boundaries of the phases then correspond to the anchor points. 3 The multiple V-model 3.1 The multiple V-model for information flow We outline "the next" model. We present the model as a template of ingredients where specific concrete ingredients can be chosen depending on the situation at hand. The entities in the information flow model are activities (that transform artifacts). The relationships are information flow arrows that represent the input and output information between (groups of) activities. This relation can occur at various levels: artifacts or groups of artifacts Entities 1. At the lowest level of detail the following entities are identified. An activity: the basic unit of work. Examples are: user requirements elicitation, deciding on requirement attributes, implementing tests, establishing connections for tracing, applying a metric to code and handling of certain change requests. Input for an activity is a set of artifacts (documents, code, tests,...) Output from an activity is a set of artifacts. We take the activities as the leading entity for grouping. The activities are then grouped in various ways. 2. A Task: a group of activities. - A Task groups a set of activities that are closely related and that cooperate to produce a common set of output artifacts. Information flow between activities within a box is informal. For example, the activities static and dynamic problem modeling and documenting these models are executed iteratively until the model and documentation are complete. The common input artifacts for these activities are requirements and use cases; the output artifact is the documentation of the problem analysis. The result of these activities at the end of the development process or of, e.g., a RUP phase is a set
7 of baselined output artifacts. At such moments, the information dependencies dictate the consistency of dependent artifacts with the artifacts that these depend on. At the end of the development process, it is impossible to distinguish what kind of process has been executed to produce the artifacts: it could have been a Waterfall or a RUP process. Input for a Task is a set of artifacts (namely, the ones needed for the activities of that phase). Output for a Task is a set of artifacts (namely, the ones produced by the activities of that phase). Examples of Tasks are: requirements engineering, integration testing, or requirements management for a particular Task. NB The activities within a Task may well have an iterative character. This is not indicated at the information flow level of the multiple V-Model, but is described at the Process Model level. 3. A V: groups Tasks by nature. Our motivation for the V-shape is, that an important (information flow rather than timing) ordering on the Tasks (in the various perspectives) is, where the Task occurs in the course of decompositional (downward left in the V) or compositional (upward right in the V) development. Corresponding decomposition/composition steps need information transfer; this is easy to depict when they are at opposite positions in the V. As mentioned above, we group several of RUP s workflows into a single Realization V. Given the dependencies, the information flows between these workflows seem adequately modeled in a single V. 4. A set of Vs: gives total development Because the development tasks differ in nature, several Vs are used. For example, a realization-v, a Test-V, a Requirements management-v, a Project Management-V, a Configuration and Change Management-V. Note that also information flow arrows between the Vs occur. For example, effort registration from each Task to the Project Management-V Relationships (in progress) Input for an activity is a set of artifacts (documents, code, tests,...) Output from an activity is a set of artifacts. This information can come from or be used by various activities and therefore flows between phases and between Vs. We take the activities as the leading entity for information flow, but further detail which artifacts are used. Relationship arrows indicate information flow; there are three (relevant) levels of detail at which arrows can connect entities: - between Artifacts; - between Activities; - between Tasks. This leads to arrows at different levels of detailing: - at the task level, an arrow between tasks indicates that output from one phase is used as input for the other task.
8 - at the activities level, an arrow between activities means that the output of one activity is used as input for the other activity. - at the artifact level, an arrow indicates that an artifact is used as input for an activity. It might even be possible in certain cases to identify that an input artifact is relevant for certain but not all output artifacts of an activity. Note, that for the management of change impact it makes a difference at which level the information flow arrows are available. NB It is quite possible to choose the activities, tasks, Vs and relationships in any order. Multiple V
9 Realization-V Verification and Validation-V 3.2 Process (in progress) The timing is treated separately, as various kinds of process, e.g., top-down, bottom-up, spiral, extending the multiple V model with time arrows. NB Many issues to be considered: - what is the difference between a spiral model and several iterations through a waterfall? maybe that in the spiral case there is info flow from the same phases on different rings of the spiral. This is interesting, as it is information flow that cannot be depicted in the model without time, as there are no rings there.
10 Processes Tooling At least for separate Vs, but more challenging: 1. To join Vs 2. To handle also process (i.e., timing) 4 Conclusions References [Bo76] Boehm, B.W., Software Engineering, IEEE Transactions on Computers, C-25, pp , [Bo88] Boehm, B.W., A Spiral Model of Software Development, and Enhancement, Computer, (21,5) pp 61-88, [Bo96] Boehm, B.W., Anchoring the Software Process, IEEE Software, July 1996, pp 73-82, [Br86] Rook, P., Controlling software projects, Software Engineering Journal, January 1986, pp 7-16, [Co95] Cockburn, A., "Unraveling Incremental Development", Object Magazine, Jan. 1995, pp [Co97] Using "V-W" Staging to Clarify Spiral Development, [IABG95] (start page), (process model). [JBR99] Jacobson, I., Booch, G., Rumbaugh, J. The Unified Software Development Process, Addison-Wesley, [Kr00] Kruchten, P., The Rational Unified Process: An Introduction (2nd Edition), Addison- Wesley, [!!] ITEA site [??] some reference to more-vs model.
11 1. This is for component DEVELOPMENT, now change also: take care of What is changing and what is touched. 2. How to match this with the ideas of IEESE and Stefan? 3. How to use Deifel in here? 4. How to use Antje von Knethen's ideas? 5. How to use TUE's incremental verification? 6. How to use Selliers' ideas? 7. What about FOCUS? 8. What about ISpec? UNUSED IDEAS NB Subdivision of workflow Vs into phases: according to granularity of artifacts; also information flow is decisive. NB Traversal of cycle should also be possible for obtaining iteratively 1 generation. NB Idea of emphasis on cycle phases is close to customizable cycle, but also gives management info about resources needed OLD STUFF The multiple V-model The following is based on results from the ITEA-DESS project [!!] From the above observations it follows that in fact three things are modeled: I. The development activities and their grouping... This regards information transformation. 1. activities - smallest unit of development activity 2. phases - groups of activities; grouped according to I/O artifacts that address same entity ***is
12 that so, and should I/O be only for phases or also for activities?*** 3. workflows - V-shaped groupings of phases; (ordered according to information flow ***maybe under II?***), grouped according to same nature NB Depending on situation, various choices for the Vs can be made. Basic: realization V, Validation V, Test (or Verification ***you were right about the naming conventions, Erik, I looked it up in the IEEE glossary - verification is testing, blurf...***), Requirement Management V. Less basic: Process management V, Quality management V, C***?*** and Change Management V. II. Information flow between phases in workflows... This regards information dependency. NB Arrows go from output to input, selecting from a set of output artifacts the artifact that needed in a set of input artifacts: many arrows may go in. ***NB Don't forget to mention somewhere that feedback is considered a different kind of information flow than during development: no clear I/O artifacts, treated as only occurring during instable situation*** III. Time order between development activities.... This is process: for a given V add a separate timing schedule. See below. We propose to separate information flow and timing. This leads to modeling 1 and 2 together, and separately model timing of the various phases as various processes: bottom up, top down, middle out, spiral. 1. a model, the triple V-model for the information flow between phases of workflows. 2. a separate description, in terms of the (workflows and?) phases of the triple V model of the timing. *** I am not convinced that all perspectives are Vs: for example, project management or versioning may well have another relation to some set of Vs rather than being a V itself. To be considered: what happened to the classical notions of decomposition and abstraction? decomposition: split of activities inside phases over components, maybe orthogonal part of Vs? Or organized by RM? abstraction? maybe present in how detailed one looks at the artifacts in the Vs? And how does that relate to the information flow? maybe something like a view - different from a perspective (perspective is a certain area of work, a view is than the level of abstraction chosen to work in that perspective.)
Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation
CHAPTER_3 SOFTWARE ENGINEERING (PROCESS MODELS) Prescriptive Process Model Defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high quality
3.0 Methodology 3.1 Introduction In this chapter, five software development life cycle models are compared and discussed briefly. The most suitable system methodology for the proposed system is drawn out.
CS4507 Advanced Software Engineering Lectures 2 & 3: Software Development Lifecycle Models A O Riordan, 2015 Some diagrams from Sommerville, some notes from Maciaszek/Liong Lifecycle Model Software development
I219 Software Design Methodology JAIST Master s Program Fall 2014 Nguyen Van Vu email@example.com Topics Course Introduction Objectives and Scope Evaluation Policies Content and Schedule Basic Concepts
3C05: Unified Software Development Process 1 Unit 5: Unified Software Development Process Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases 2
Software Engineering So#ware Processes 1 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification defining
2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
Unified Process Family: Iterative Enhancement Origin: Ivar Jacobson, James Rumbaugh, Grady Booch, 1996 Defines process framework that is adaptable to various application domains different organizations
1 Software Engineering Lecture 2: Software Life Cycles Stefan Hallerstede Århus School of Engineering 25 August 2011 2 Contents Naive Software Development Code & Fix Towards A Software Process Software
Title: Topic 3 Software process models (Topic03 Slide 1). Topic 3: Lecture Notes (instructions for the lecturer) Author of the topic: Klaus Bothe (Berlin) English version: Katerina Zdravkova, Vangel Ajanovski
Session # 3 Contents Systems Analysis and Design 2 1 Tiers of Software Development 10/4/2013 Information system development project Realistic behavior 3 Information system development project System Development
In this Lecture you will Learn: Development Chapter 5C About the Unified Software Development How phases relate to workflows in an iterative life cycle An approach to system development Major activities
Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky
What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each
The Unified Software Development Process Technieche Universal Darmstadt FACHBEREICH IN-FORMAHK BLIOTHEK Ivar Jacobson Grady Booch James Rumbaugh Rational Software Corporation tnventar-nsr.: Sachgebiete:
Amir Tomer Amir Tomer is the Director of Systems and Software Engineering Processes at RAFAEL Ltd., Israel,with whom he has been since 1982,holding a variety of systems and software engineering positions,both
A FRAMEWORK FOR INTEGRATING SARBANES-OXLEY COMPLIANCE INTO THE SOFTWARE DEVELOPMENT PROCESS Sushma Mishra Virginia Commonwealth University firstname.lastname@example.org Heinz Roland Weistroffer Virginia Commonwealth
Fundamentals: Software Engineering Dr. Rami Bahsoon School of Computer Science The University Of Birmingham email@example.com www.cs.bham.ac.uk/~rzb Office 112 Y9- Computer Science Unit 1. Introduction
Best-Practice Software Engineering: Software Processes to Support Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems Dietmar.Winkler@qse.ifs.tuwien.ac.at
Component Based Development in Software Engineering Amandeep Bakshi, Rupinder Singh Abstract--In today s world, Component Based development is an active research area for more than a decade in software
Slide 3.1 Development Methodologies Prof. Dr. Josef M. Joller firstname.lastname@example.org Development Methodologies Prof. Dr. Josef M. Joller 1 Session 3 Slide 3.2 SOFTWARE LIFE-CYCLE MODELS Development Methodologies
Central Page 284 of 296 Application of software product quality international standards through software development life cycle Mladen Hosni, Valentina Kirinić Faculty of Organization and Informatics University
Software Development Process Models and their Impacts on Requirements Engineering Organizational Requirements Engineering Prof. Dr. Armin B. Cremers Sascha Alda Overview Phases during Software Development
Supporting Workflow Overview CSC532 Fall06 Objectives: Supporting Workflows Define the supporting workflows Understand how to apply the supporting workflows Understand the activities necessary to configure
Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 20-21 The Unified Process Dynamic dimension Two dimensions Content
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) ANALYTICAL COMPARISON AND SURVEY ON TRADITIONAL AND AGILE METHODOLOGY Sujit Kumar Dora 1 and Pushkar Dubey 2 1 Programmer, Computer Science & Engineering, Padmashree
SE464/CS446/ECE452 Software Life-Cycle and Process Models Instructor: Krzysztof Czarnecki 1 Some of these slides are based on: Lecture slides by Ian Summerville accompanying his classic textbook software
Software Corporation Software Project Management using an Iterative Lifecycle Model 1 Objectives of this Presentation To understand what the Unified Process is To understand the iterative lifecycle approach
CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process
A Rapid Development Process with UML Giuliano Armano DIEE, Dipartimento di Ingegneria Elettrica ed Elettronica, University of Cagliari Piazza d Armi I-09123, Cagliari (Italy) Tel. +39-70-675.5878 email@example.com
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...
CONTENTS 1.SOFTWARE-DEFINITION 2.TYPES OF SOFTWARE 3.SOFTWARE DEVELOPMENT 4.SOFTWARE LIFECYCLE 5.WATERFALL MODEL 6.ITERATION MODEL 7.V SHAPED MODEL 8.SPIRAL MODEL SOFTWARE DEVELOPMENT SD MODULE 1 1.SOFTWARE:
PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main
Systeme hoher Qualität und Sicherheit Universität Bremen, WS 2013/14 Lecture 03 (04.11.2013) Quality of the Software Development Process Christoph Lüth Christian Liguda Your Daily Menu Models of Software
International Journal of Research in Information Technology (IJRIT) www.ijrit.com ISSN 2001-5569 A Comparison between Five Models of Software Engineering Surbhi Gupta, Vikrant Dewan CSE, Dronacharya College
6. Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project. Hundreds of different kinds of models are known and used.
6 Contracts and Scenarios in the Software Development Process Summary: Software development processes play an important role in the successful and timely delivery of software. There are different approaches
Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or
Volume 4, Issue 6, June 2014 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Comparative Analysis
IBM Software Group Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK Jean-Louis Maréchaux Software IT Specialist IBM Rational
In this Lecture you will Learn: Systems Development Methodologies What a systems development methodology is Why methodologies are used The need for different methodologies The main features of one methodology
Rational Unified Process Process Description and Workflows Mike Fourman Describing Processes The RUP uses four elements to describe processes: Workers describe a role, some people have many roles. Activities
Software Design Models, Tools & Processes * Lecture 1: Software Design and Software Development Process Cecilia Mascolo * Thanks to Alan Blackwell and Jim Arlow for le7ng me use some of their slides. About
Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process
Unit I Introduction Product Life Cycles Products also have life cycles The Systems Development Life Cycle (SDLC) is a framework for describing the phases involved in developing and maintaining information
An Iterative and Agile Process Model for Teaching Software Engineering Maria Isabel Alfonso and Antonio Botía Dept. of Computer Science and Artificial Intelligence. University of Alicante (Spain) firstname.lastname@example.org,
Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called
Software Development Life Cycle Models- Comparison, Consequences Abstract- Software Development Life Cycle is a well defined and systematic approach, practiced for the development of a reliable high quality
ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: A Comparative Analysis of Different types of Models in Software
Software Development Process A software development process, also known as software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software
RUP for Software Development Projects George Merguerian www.bmc-online.com 1 Specialists in Global Project Management Brussels Frankfurt Houston Istanbul Milan Ottawa Shanghai Singapore Warsaw Washington
Paper published in: Crosstalk, 9 (7) July 1996, pp.11-16. A Rational Development Process Philippe Kruchten Vancouver, BC email@example.com 1. Introduction This paper gives a high level description of the
A Survey of Plan-Driven Development Methodologies Plan-driven methodologies have been utilized by organizations for many years. In this chapter, we provide an overview of three prominent, modern plan-driven
Development/Maintenance/Reuse: Software Evolution in Product Lines Stephen R. Schach Vanderbilt University, Nashville, TN, USA Amir Tomer RAFAEL, Haifa, Israel Abstract The evolution tree model is a two-dimensional
, pp. 213-220 http://dx.doi.org/10.14257/ijseia.2014.8.10.19 A Review of an MVC Framework based Software Development Ronnie D. Caytiles and Sunguk Lee * Department of Multimedia Engineering, Hannam University
Robust Object Oriented System Analysis Dr Jie Zhao, Dunstan Thomas Consulting Summary Uses cases are widely accepted as the best approach to capturing system requirements, in particular, functional requirements.
Günter Böckle Klaus Pohl Frank van der Linden 2 A Framework for Software Product Line Engineering In this chapter you will learn: o The principles of software product line subsumed by our software product
202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering
Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an
Software Development Process and Activities CS 490MT/5555, Fall 2015, Yongjie Zheng Software Process } A set of activities that leads to the production of a software product } What product we should work
RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall
Vol. 5 No. 3, July, 2011 Redesigned Framework and Approach for IT Project Management Champa Hewagamage 1, K. P. Hewagamage 2 1 Department of Information Technology, Faculty of Management Studies and Commerce,
Plan-Driven Methodologies The traditional way to develop software Based on system engineering and quality disciplines (process improvement) Standards developed from DoD & industry to make process fit a
Software Engineering for Software-Intensive Systems: III The Development Life Cycle Assistant Professor Dr. Room E 3.165 Tel. 60-3321 Email: firstname.lastname@example.org Outline I Introduction II Foundations III The Development
Introduction to Software Project Management CITS3220 Software Requirements & Project Management "A project gets a year late one day at a time." "Anything that can be changed will be changed until there