A Look at Software Engineering Risks in a Team Project Course
|
|
- Warren Watson
- 8 years ago
- Views:
Transcription
1 A Look at Software Engineering Risks in a Team Project Course Supannika Koolmanojwong and Barry Boehm Center for Systems and Software Engineering (CSSE) University of Southern California (USC) Los Angeles, CA, , USA {koolmano, boehm}@usc.edu Abstract Risk identification, management, and mitigation are essential to the success of any software development projects. At the University of Southern California (USC), CSCI577ab is a graduate level software engineering course sequence that teaches the best software engineering practices, and allows students to apply the learned knowledge in developing real-client projects. This paper analyzes the risks encountered by teams, identifies the relationships between effective risk analysis and the success of the project, and discusses how risk patterns determine the student s course of action. This paper also reports the top risks of software development in the software engineering class. 1. Introduction It is common to have risks in a software development project. Risk can come with opportunities for the risk takers to lead a project to a different course of action, or to successful development. At the same time, risks can also lead a project to failure and disaster. Hence, risk management is an essential topic in any software engineering course. There are many ways to introduce the concept of risk management to the class, such as using games [14], risk assessment tools [7], or educational case studies [10][13]. In our CSCI577-graduate level software engineering class, as part of the software development process, student teams learn how to identify, analyze, mitigate and manage the risks in their real-client team projects [5]. The data collected through weekly risk reports using a tool called Distributed Assessment of Risk Tool (DART), milestone reports, and additional surveys are used to identify the top ten risks in software team projects, and to show how the risks determine different project life cycle processes. A software engineering class is similar to a software engineering project in a sense that, at the end of each project and class, one should perform retrospective analysis and find out improvement opportunities. Risks that occur in each project should be compiled and analyzed so that the project managers will know the weak points and strong points of the project so that they will not repeat the same simple mistakes in the future projects. Similarly, the course instructor should learn from previous class projects and prepare lectures, homework exercises, or supplementary information for the next class. The rest of the paper is organized as follows. Section 2 elaborates on the nature of the software engineering class and, the Incremental Commitment Spiral model which is used as a main process model for the software engineering class. Section 3 reports the risks found in the software engineering class, comparing them to risks found in the industry. Section 4 elaborates on the relationship between risk management performance and project performance. Section 5 shows how risk patterns can determine a course of action and how they may drive different development life cycles for each project. 2. Related Works
2 2.1. The Software Engineering Team Project Class CSCI577ab [6] is a graduate level software engineering course at the University of Southern California (USC). The main objective of the course is to prepare students for software leadership careers through the 2050 s. Software Engineering I or CSCI577a focuses on software plans, processes, requirements, architectures, risk analysis, and feasibility analysis. Software Engineering II focuses on software product creation, integration, test, and maintenance with an emphasis on quality software production. Each year, students are self-organized into teams of six on-campus and two off-campus students to develop projects or e-services projects for real-clients in effectively 24 weeks. The clients are primarily from various USC departments, neighborhood corporations, local government agencies, and community service organizations. Oncampus students act as operational concept engineers, requirements engineers, software architects, UML modelers, coders, life cycle planners, and feasibility analysts. Offcampus students act as Integrated Independent Verification and Validation (IIV&V) personnel. The course staff teach and use evolving best practices, techniques and tools such as requirement management, object-oriented analysis and design, risk management, quality management, peer reviews, configuration management, and valuebased software engineering. Risk management is a core activity in CSCI577ab. On a weekly basis, by using the Distributed Assessment of Risks tool (DART), all team members have to brainstorm to identify the risks. For each risk item, each team member identifies the probability of risk occurrence (0-10) and the size of loss (0-10) in order to identify risk exposure for each risk item. Risk exposure can be calculated by multiplying the probability of loss to the size of loss. Team members, together with the clients, discuss the resulting risk mitigation plans. The project manager takes the top ten risks and reports them in his/her weekly progress report. Additionally, for each milestone, the teams have to present their current risks and mitigation plans to the architecture review board as evidence of project feasibility. The authors, as the course staff, review and monitor the project risks The Incremental Commitment Spiral Model The ICSM [4][11] is a process model covering the full system development life cycle consisting of the Exploration phase, Valuation phase, Foundations phase, Development phase, and Operation phase. ICSM, as shown in Figure 1, has been shown to be effectively tailorable to a wide variety of system development situations. The four underlying principles of the ICSM include a) stakeholder value-based system definition and evolution, b) incremental commitment and accountability, c) concurrent system and software definition and development, and d) evidence and risk-based decision making. Evidence of project feasibility is the key ingredient to avoid the risks, and can be used to determine the future of the project. Our Software Engineering class uses the ICSM as its software development process model. Exploration, Valuation, and Foundations phases are in CSCI577a in the fall semester. To accommodate the possible changes during the winter break, once the spring semester begins, the teams execute a Rebaselined Foundations phase and proceed to the Development phase. Final project delivery marks the beginning of the Operation phase. Hence, our software engineering project activities end with the project transition, training, and the early phase of deployment. As shown at the bottom of Figure 1, at the end of each milestone, current project risks determine the possible project direction. More information can be found in Section 5.
3 Figure 1. Overview of the Incremental Commitment Spiral Model [4] 3. Top Risks in Software Engineering Class Projects Risk management is one of the fundamental activities in industrial software development. For each project, risks can be different based on their characteristics. Examples of traditional risks [1] are personnel shortfalls, requirements volatility, architecture complexity, and quality tradeoffs. For internet and intranet software development, the volatile technology requires rapid changes in methods and tools. Some of today s risks are quite different from the risks that we had 10 years ago due to the fast pace of technologies [12]. Table 1 summarizes the risk categories and example risk items found in our software engineering class. In general, risks found in our class are similar to risks in the industry. However, it is important to mention that some risks are found more often in the software engineering class, for example: No maintainer Since the class will end after the product is delivered, it is the client s responsibility to find a system maintainer or administrator. Since most clients are nonprofit small-scale organizations, it is a challenge for clients to appoint, hire, or learn to be a maintainer. Process maturity and quality assurance To support the concepts of process maturity and quality assurance, the class provides guidelines and tools for student teams to learn about such good practices as configuration management and quality management. But with a very steep learning curve of learning about the project and process at once, student teams might not be able to digest and follow all suggested process guidelines. Acquisition In various projects, the client has to acquire additional hardware, such as a mobile device or a scanner. However, most of the clients are non-profit organizations,
4 they also have problems of budget constraints. Hence, sometimes the clients were not able to acquire the required infrastructure as planned. Personnel capability Most on-campus students came directly from the undergraduate level with limited software development experience. Thus, they are learning software engineering and other computer science skills on the fly, and hence they have limited personnel capability. Risk Category Architecture complexity; quality tradeoffs Budget, schedule and resource constraints COTS and other independently Evolving systems Customer-developer-user team cohesion Personnel shortfalls Requirements mismatch Requirements volatility; rapid change User interface mismatch Process Maturity Lack of domain knowledge Acquisition and contracting process mismatches Others Table 1. Risk Categories and Examples Example of risk items Maximum optimization system design; generalizing the design modules for future evolutionary needs 24 week development schedule; often a zero monetary budget and limited computing power Unknown COTS infrastructure, unreliable COTS performance, COTS interoperability, future scalability Off-campus students work full time in different time zone, difficult to find a good meeting time slot Lack of technical and software engineering knowledge; personnel turnover, unknown maintainer Requirements-architecture mismatch New stakeholders emerge with different visions, hence different requirements. GUI may be too complex for non-technical users Possibility of inconsistent data due to team members not following the configuration management plan Learning curve about domains such as health care and business processes; Beyond Computer Science scope Often the clients are unable to provide special devices for testing as initially envisioned Migration complexity As the project progresses, student teams, together with the clients, have identified their risks in the weekly report. The risks collected from 86 teams from Fall 2005 Spring 2010 are analyzed to determine the possible categories of risks, frequency of risks and possible risk rankings. Figure 2 presents the percentage of frequency of risks in each category that occur during the project development. The blue columns represent risks that occur in the fall semester or Exploration, Valuation, and Foundations phases. The red columns represent risks that occur in the spring semester or Development and early Operation phase. The columns are sorted by average percentage of risk occurrence. As shown in Figure 2, the risk occurrence in the fall semester is uniformly higher than the risk occurrence in the spring semester. The risks that involve a learning curve such as process maturity, or lack of domain knowledge, are much lower in the spring semester.
5 Figure 2. Percentage of Risk Occurrence in each category Figure 3. Summary of Risk Ranking in Each Category On the other hand, for each risk, student teams have to calculate the risk exposure, which is the possibility of risk multiplied by the size of the loss. The Top Ten Risks List is determined by summing the risk exposure of each risk item. Figure 3 represents the summary of each risk ranking. The blue columns represent the risks in the fall semester, while the red columns represent the risk in the spring semester. While there are fewer risks and lower risk exposure in the spring semester, it is interesting to note that the risks about user interface mismatch remain the same in the spring semester. The result of the summary of risk ranking implies how difficult or significant each risk is, while the percentage of risk occurrence refers to how long the risk lasts. A comparison between Figure 2 and Figure 3 has shown that in general, the more difficult the risk is, the
6 longer the risk lasts. There are also some exceptional cases such as COTS and independently evolving systems risks, although Figure 2 shows that risk occurrence remains the same in the spring semester, but Figure 3 shows that the team put less weight to this risk possibly because this risk is beyond the team s controllability. During the product implementation and transition, the COTSs are working fine, however, since the team and the client have no control over its next release, so there is always a risk of future loss of interoperability or support from COTS vendor due to the changes from COTS. Table 2 reports the comparison between the top ten risks in industry in 1991[1] and a survey of the top ten risks in the industry in 2007 [2], as well as a summary of the top ten risk ranking based on 86 teams of the software engineering classes from Since these teams are working in an academic setting where the group is only together for fifteen weeks in the first semester, there are many more challenges students face while identifying/mitigating risks in comparison to those who work in industry. Due to the time constraint, student team members face a high learning curve where they must understand the client s project requirements, as well as buy into the team and client dynamic. Misinterpreting and/or not fully understanding the client s requirements can result in the high risk of developing software that is not up to the client s standards/objectives, and may require having to revisit requirements later on in the development phase. The lack of buy-in from all personnel involved can result in the high risk of apathy where team members are not motivated to contribute. In addition, during two-semester project classes like CSCI577, there is a high team member turnover rate since some students do not continue onto the next semester. Losing a team member greatly impacts the progress of a project since responsibilities must be reassigned to existing members or, a new member may be brought in forcing the team has to re-calibrate. Table 2. Comparison of Top 10 risks Top 10 Software Risk Items (Boehm 1991) [1] 1. Personnel shortfalls 2. Unrealistic schedules and budgets 3. Requirement mismatch Top 10 Risks in Software industry (Boehm 2007) [2] 1. Architecture complexity, quality tradeoffs Top 10 Risks in Software engineering class (2010) 1. Architecture complexity, quality tradeoffs 2. Requirements volatility 2. Personnel shortfalls 3. Acquisition and contracting process mismatches 4. User Interface mismatch 4. Budget and schedule 5. Gold plating 5. Customer-developer-user 3. Budget and schedule constraints 4. COTS and other independently evolving systems 5. Customer-developer-user team cohesion 6. Requirement volatility 6. Requirements mismatch 6. Requirements volatility 7. Shortfalls in externally furnished components 7. Personnel shortfalls 7. User interface mismatch 8. Shortfalls in externally performed tasks 8. COTS 8. Process Quality Assurance 9. Real-time performance shortfalls 9. Technology maturity 9. Requirements mismatch 10. Straining computer 10. Migration complexity 10. Acquisition and
7 science capabilities contracting process mismatches Comparing to the industry settings, these challenges do not traditionally exist in the industry since many software engineering projects take years to complete. By increasing the development time of a project, the team has more time to gain a better understanding of the client s needs and to determine requirements that are agreed upon by all stakeholders before implementation begins. This lowers, and sometimes even mitigates, the risks of requirements mismatch/volatility. In addition, the more time a team has to work together on a project, the more time they have to mitigate group dynamic and personnel shortfall risks before team cohesion becomes crucial to the success of the project. Since there are also monetary motivations while working in the industry, project members have more of a vested interest in contributing to the project and seeing it succeed. A student is mostly motivated by grades, and often striving for high grades is not of value to some students and their performance in team projects is an additional project challenge. Figure 4. Relationship between Risk Management and Team Performance 4. Risk Management Process and Team Performance In 2008, a survey was conducted to assess how risks have impacted the teams project progress and how the Incremental Commitment Spiral Model s effectiveness in managing risks. Five questions were asked of eight teams in the spring semester. Figure 4 reports the results of the survey. The vertical axis represents the rating value and the horizontal axis represents the teams, which are ordered by their performance (grade). Dotted lines represent
8 their perspective about the risk management in the fall semester, and solid lines represent their perspective for the spring semester. Based on their self-evaluation, in general there is a relationship between the grade performances of the groups as well as how well they believed they worked as a group in mitigating risks. Looking at Figure 4 from a very high level, there is a negative slope. This means that the lower their risk assessment and management ratings (1 = unsuccessful and 10 = very successful), the lower the grade they received on the final project. Therefore, there is a correlation between group success as a team, its ability to identify and manage risks, and the overall project outcome. However, Group C shows the exceptional case. In the fall semester, Group C did not perform well and has a high personnel turnover while in the spring semester, Group C got new team members who rescued the team. The dotted lines for Group C shows that they realized that they have not managed the risks well in the fall semester, but they have improved in the spring semester, reflecting their team s performance. On the other hand, in spring semester, Group F knows they have high architectural complexity risks, but they are struggling in managing and mitigating the risks, as shown in the light blue line graph. 5. Risk-Driven Development Process Risk identification supports the team in determining a course of action as illustrated at the bottom of Figure 1, and Figures 5 and 6. Based on the ICSM key principle about risk-based decision making, a risk analysis result can be categorized into four distinct types: A) If a risk is acceptable, the team can move forward to the next phase. B) If a risk is negligible, the team can skip a phase, or spend little or no time in the next phase. This situation could happen when the team finds a perfect commercial-off-the-shelf (COTS) or web service that provides all required functionalities. The team could skip the Valuation phase and Foundations phase since the team does not have to spend time prototyping or defining the architecture. C) If the risk is too high but still addressable, the team might need to repeat the current phase until the risk is mitigated and the team is ready to move forward to the next phase. D) If the risk is too high and unaddressable, the team should consider halting the project in order to adjust the scope and priorities or, possibly discontinue the project. This could happen when the project is found to be unfeasible within the defined budget or schedule. On the other hand, in the commercial setting, if the competitor has already launched a product that has similar functionalities, the team should redirect the project in order to gain a competitive advantage. Figure 5 shows a typical risk pattern in a software engineering project with acceptable risks, satisfactory feasibility evidence, and committed success critical stakeholders. Figure 5. Risk Pattern Driving in Repeating Exploration Phase [8]
9 Based on an analysis of the risk patterns in 14 software engineering projects in Fall 2009 Spring 2010, 9 out of 14 teams had addressable risks with smooth project progress toward the Operation phase. As shown in Figure 5, 3 of the 14 teams had unclear project scopes. The teams are not ready to move forward to the Valuation phase, hence the teams briefly spent extra time in the Exploration phase to discuss and gather more information from the successful critical stakeholders, exploring additional alternatives and conducting additional prototyping. Figure 6. Risk Pattern Driving in Repeating Adjusting Scope and Priorities [8] One team proceeded from the Exploration to the Foundations phases with acceptable risks, as shown in Figure 6. But during the Development phase, the team found that there were applicable Net-Centric Services. Hence, the team went back to the Exploration phase to perform detailed COTS assessments, and bypassed the Valuation and Foundations phases since the selected web service provides most of the required functionalities. 6. Conclusions Team project courses have difficult front-loading problems in that students need to do a just-in-time learning about how to select and organize team members, how to interact with project clients to understand their needs and environment, how to assess candidate off-theshelf packages addressing the needs, how to negotiate feasible requirements, how to develop project plans, and how to define the system s architecture. Initially, we did not include risk assessment and management in this up-front material, but soon found that it was often success-critical for teams to be able to identify, assess, and manage their risks. This involved us in preparing lectures, homework exercises, tools, and tutorials for risk identification, assessment and management that significantly increased the projects success ratings.
10 As the software field has evolved from having mostly programming-intensive projects to non-developmental-item / open source / COTS / cloud services projects, we have found that the risk patterns, sources, frequencies, and potential impacts have changed significantly. The data, guidelines and evolved processes presented in this paper, should help project courses incorporate risk considerations in their students learning venues. 7. References [1] Boehm, B., "Software Risk Management: Principles and Practices," original version of IEEE Software, Volume 8, Issue 1, January 1991, pp [2] Boehm, B., Top 10 Software-Intensive Systems Risk Items, Presentation at USC Annual Research Review [3] Boehm, B. and Bhuta, J., "Balancing Opportunities and Risks in Component-Based Software Development," IEEE Software, November-December 2008, Volume 15, Issue 6, pp [4] Boehm, B. and Lane, J., Using the Incremental Commitment Model to Integrate Systems Acquisition, Systems Engineering, and Software Engineering, Cross Talk, October 2007, pp.4-9 [5] Boehm, B. and Port, D., "Educating Software Engineering Students to Manage Risk," ICSE, pp.0591, 23rd International Conference on Software Engineering (ICSE'01), 2001 [6] CSCI577ab Software Engineering Class Website, [7] Groth, D.P.; Hottell, M.P.;, "How Students Perceive Risk: A Study of Senior Capstone Project Teams," Software Engineering Education & Training, CSEET '07. 20th Conference on, vol., no., pp.45-54, 3-5 July 2007 [8] Koolmanojwong, S. "The Incremental Commitment Spiral Model Process Patterns for Rapid-Fielding Projects," PhD Dissertation, Department of Computer Science, University of Southern California, December 2010 [9] Koolmanojwong, S. and Boehm, B., "The Incremental Commitment Model Process Patterns for Rapid- Fielding Projects," ICSP 2010, Paderborn, Germany [10] Mead, N.R., et.al, "Ensuring Cost Efficient and Secure Software through Student Case Studies in Risk and Requirements Prioritization," hicss, pp.1-9, 42nd Hawaii International Conference on System Sciences, 2009 [11] Pew, R. W., and Mavor, A. S., Human-System Integration in the System Development Process: A New Look. 2007, National Academy Press. [12] Reifer, D., Ten Deadly Risks in Internet and Intranet Software Development, IEEE Software, March- April 2002, Issue 6, pp [13] Swart, R.S, Erbacher, R.F., Educating Students to Create Trustworthy Systems, IEEE Security and Privacy, v.5 n.3, p.58-61, May 2007 [14] Taran, G. "Using Games in Software Engineering Education to Teach Risk Management," cseet, pp , 20th Conference on Software Engineering Education & Training (CSEET'07), 2007
Educating Software Engineers to Become Systems Engineers
Educating Software Engineers to Become Systems Engineers Supannika Koolmanojwong and Barry Boehm Center for Systems and Software Engineering (CSSE) University of Southern California (USC) Los Angeles,
More informationUSC's Two Semester Software Engineering Graduate Project Course
USC's Two Semester Software Engineering Graduate Project Course A. Winsor Brown Computer Science and USC Center for Systems and Software Engineering, University of Southern California Los Angeles, CA 90089-0781,
More informationThe Incremental Commitment Model Process Patterns for Rapid-Fielding Projects
The Incremental Commitment Model Process Patterns for Rapid-Fielding Projects Supannika Koolmanojwong and Barry Boehm Center of Systems and Software Engineering University of Souther California Los Angeles,
More informationSoftware Engineering Graduate Project Effort Analysis Report
Software Engineering Graduate Project Effort Analysis Report Zhihao Chen Center for Software Engineering, University of Southern California, Los Angeles 90089 California, USA {zhihaoch}@cse.usc.edu Abstract:
More informationA Risk-Driven Decision Table for Software Process Selection
A Risk-Driven Decision Table for Software Process Selection Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong University of Southern California ICSP 2010 Keynote Outline No one-size-fits-all software process
More informationWhat is a life cycle model?
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
More informationArchitecture Centric Development in Software Product Lines
Architecture Centric Development in Software Product Lines Aurangzeb Khan DCE, College of E & ME National University of Science and Technology (NUST), Pakistan Farooque Azam DCE, College of E & ME National
More informationSoftware Development Life Cycle (SDLC)
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
More informationSoftware Engineering and the Systems Approach: A Conversation with Barry Boehm
IGI PUBLISHING ITJ4305 701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USA Int l Journal of Tel: Information 717/533-8845; Technologies Fax 717/533-8661; and the Systems URL-http://www.igi-global.com
More informationPhases, Activities, and Work Products. Object-Oriented Software Development. Project Management. Requirements Gathering
Object-Oriented Software Development What is Object-Oriented Development Object-Oriented vs. Traditional Development An Object-Oriented Development Framework Phases, Activities, and Work Products Phases,
More informationThe ROI of Systems Engineering: Some Quantitative Results
The ROI of Systems Engineering: Some Quantitative Results Barry Boehm Center for Systems and Software Engineering University of Southern California boehm@usc.edu Ricardo Valerdi Lean Aerospace Initiative,
More information(Refer Slide Time: 01:52)
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
More informationCost Estimation Strategies COST ESTIMATION GUIDELINES
Cost Estimation Strategies Algorithmic models (Rayleigh curve Cost in week t = K a t exp(-a t 2 ) Expert judgment (9 step model presented later) Analogy (Use similar systems) Parkinson (Work expands to
More informationEvaluation and Integration of Risk Management in CMMI and ISO/IEC 15504
Evaluation and Integration of Risk Management in CMMI and ISO/IEC 15504 Dipak Surie, Email : ens03dse@cs.umu.se Computing Science Department Umea University, Umea, Sweden Abstract. During software development,
More information<name of project> Software Project Management Plan
The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor
More informationKnowledge-Based Systems Engineering Risk Assessment
Knowledge-Based Systems Engineering Risk Assessment Raymond Madachy, Ricardo Valerdi University of Southern California - Center for Systems and Software Engineering Massachusetts Institute of Technology
More informationIncreasingly rapid IT changes require software development projects to continuously
focus oppor t unis t ic s o f t w ar e s y s t ems development Balancing Opportunities and Risks in Component- Based Software Barry Boehm, University of Southern California Jesal Bhuta, Infosys The Incremental
More informationA Capability Maturity Model (CMM)
Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability
More informationBalancing Plan-Driven and Agile Methods in Software Engineering Project Courses
Computer Science Education 0899-3408/02/1203-187$16.00 2002, Vol. 12, No. 3, pp. 187±195 # Swets & Zeitlinger Balancing Plan-Driven and Agile Methods in Software Engineering Project Courses Barry Boehm,
More informationModern Tools to Support DoD Software Intensive System of Systems Cost Estimation
Modern Tools to Support DoD Software Intensive System of Systems Cost Estimation Jo Ann Lane and Barry Boehm University of Southern California Center for Systems and Software Engineering Abstract Many
More informationValue-Based Processes for COTS-Based Applications
focus cots integration Value-Based Processes for -Based Applications Ye Yang, Jesal Bhuta, and Barry Boehm, University of Southern California Daniel N. Port, University of Hawaii -based applications pose
More informationCS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping
More informationDemand-Driven Curriculum for Embedded System Software in Korea
Demand-Driven Curriculum for in Korea Suehee Pak Dongduk Women s University 23-1 Hawolgok-dong, Sungbuk-gu Seoul 136-714, Korea Eunha Rho Sungkonghoe University 1-1 Hang-dong, Kuro-gu Seoul 152-716, Korea
More informationThe Unified Software Development Process
The Unified Software Development Process Technieche Universal Darmstadt FACHBEREICH IN-FORMAHK BLIOTHEK Ivar Jacobson Grady Booch James Rumbaugh Rational Software Corporation tnventar-nsr.: Sachgebiete:
More informationRapid Development & Software Project Survival Guide Steve McConnell Dave Root (Developed with Mel Rosso-Llopart)
Lifecycle Planning Rapid Development & Software Project Survival Guide Steve McConnell Dave Root (Developed with Mel Rosso-Llopart) Version 1.4 David Root, 2005, all rights reserved 1 Topics Who am I to
More informationLife Cycle Activity Areas for Component-Based Software Engineering Processes
Life Cycle Activity Areas for Component-Based Software Engineering Processes Robert C. Seacord Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 USA +1 412-268-3265 Kingsley
More informationSystems Development Life Cycle (SDLC)
DEPARTMENT OF BUDGET & MANAGEMENT (SDLC) Volume 1 Introduction to the SDLC August 2006 Table of Contents Introduction... 3 Overview... 4 Page 2 of 17 INTRODUCTION 1.0 STRUCTURE The SDLC Manual consists
More informationSWEBOK Certification Program. Software Engineering Management
SWEBOK Certification Program Software Engineering Management Copyright Statement Copyright 2011. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted
More informationCDC UNIFIED PROCESS JOB AID
CDC UNIFIED PROCESS JOB AID Independent Verification & Validation Activities Document Purpose This Job Aid is a brief document listing the items to be noted, checked, remembered, and delivered when completing
More informationLecture Objectives. Software Life Cycle. Software Engineering Layers. Software Process. Common Process Framework. Umbrella Activities
Software Life Cycle Lecture Objectives What happens in the life of software To look at the life cycle of a software To understand the software process and its related elements To relate to the different
More informationLifecycle Models: Waterfall / Spiral / EVO
Lifecycle Models: Waterfall / Spiral / EVO Dror Feitelson Basic Seminar on Software Engineering Hebrew University 2011 Lifecycle The sequence of actions that must be performed in order to build a software
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,
More informationCOMP 354 Introduction to Software Engineering
COMP 354 Introduction to Software Engineering Greg Butler Office: EV 3.219 Computer Science and Software Engineering Concordia University, Montreal, Canada Email: gregb@cs.concordia.ca Winter 2015 Course
More informationTo introduce software process models To describe three generic process models and when they may be used
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
More informationPlan-Driven Methodologies
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
More informationSoftware Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution
Software Life Cycle Main issues: Discussion of different life cycle models Maintenance or evolution Not this life cycle SE, Software Lifecycle, Hans van Vliet, 2008 2 Introduction software development
More information6. Software Lifecycle Models. A software lifecycle model is a standardised format for planning organising, and running a new development project.
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.
More informationSoftware Process Engineering & Management Models
Software Process Engineering & Management Models Paul Grünbacher Institute for Systems Engineering & Automation Johannes Kepler University Linz Christian Doppler Laboratory for Automated Software Engineering
More informationCS 6361, SPRING 2010 Advanced Requirements Engineering Web Based Meeting Scheduler- Project Plan
1 W E B B A S E D M E E T I N G S C H E D U L E R S Y S T E M Project Plan Version 4.0 CS 6361 ADVANCED REQUIREMENTS ENGINEERING, SPRING 2010 UNIVERSITY OF TEXAS AT DALLAS R E Q U I R E M E N T S E N G
More informationCOTIPMO: A COnstructive Team Improvement Process MOdel
COTIPMO: A COnstructive Team Improvement Process MOdel Pongtip Aroonvatanaporn, Supannika Koolmanojwong, and Barry Boehm Center for Systems and Software Engineering University of Southern California Los
More informationSoftware Development Process
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
More informationCSE 435 Software Engineering. Sept 16, 2015
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
More informationSoftware Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville
Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when
More informationSystems Engineering with RUP: Process Adoption in the Aerospace/ Defense Industry
March 2004 Rational Systems Engineering with RUP: Process Adoption in the Aerospace/ Defense Industry Why companies do it, how they do it, and what they get for their effort By Dave Brown, Karla Ducharme,
More informationElite: A New Component-Based Software Development Model
Elite: A New Component-Based Software Development Model Lata Nautiyal Umesh Kumar Tiwari Sushil Chandra Dimri Shivani Bahuguna Assistant Professor- Assistant Professor- Professor- Assistant Professor-
More informationComponent-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3
Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 1 Mälardalen University, Västerås, Sweden, ivica.crnkovic@mdh.se 2 ABB Corporate Research,
More information21 st Century Software Engineering Trends and Challenges
21 st Century Software Engineering Trends and Challenges Barry Boehm, USC-CSSE http://csse.usc.edu SSTC Stevens Award Presentation May 18, 2011 5/18/2011 1 Outline The Future of Information Technology
More informationAn Evidence-Based Systems Engineering (SE) Data Item Description
Available online at www.sciencedirect.com Procedia Computer Science 16 (2013 ) 898 907 Conference on Syst Eds.: C.J.J. Paredis, C. Bishop, D. Bodner, Georgia Institute of Technology, Atlanta, GA, March
More informationSystem Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director
System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical
More informationSoftware Development Under Stringent Hardware Constraints: Do Agile Methods Have a Chance?
Software Development Under Stringent Hardware Constraints: Do Agile Methods Have a Chance? Jussi Ronkainen, Pekka Abrahamsson VTT Technical Research Centre of Finland P.O. Box 1100 FIN-90570 Oulu, Finland
More informationThe most suitable system methodology for the proposed system is drawn out.
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.
More informationOutline. Definitions. Course schedule
SENG480A/CSC576A Topics in Software Engineering Software Development, Architecture & Evolution Lectures, Sep 17, 20, 2001 Hausi A. Müller University of Victoria Outline Assignment 1 due Sep 27 Last week
More informationSOFTWARE ENGINEERING TEAM STUDIOS. Jaime Niño Computer Science, University of New Orleans New Orleans, LA 70148 504-280-7362 jaime@cs.uno.
SOFTWARE ENGINEERING TEAM STUDIOS Jaime Niño Computer Science, University of New Orleans New Orleans, LA 70148 504-280-7362 jaime@cs.uno.edu ABSTRACT Training of students on software engineering methods
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 12 Agile Methodologies: Crystal 1 Crystal Introduced by Cockburn as a family of methodologies in 1998. New members of the family were defined
More informationCost Estimation for Secure Software & Systems
Background Cost Estimation for Secure Software & Systems Ed Colbert Dr. Barry Boehm Center for Systems & Software Engineering, University of Southern California, 941 W. 37th Pl., Sal 328, Los Angeles,
More informationIn the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is:
In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: The period of time that starts when a software product is conceived and ends when the product is no longer
More informationWeaving the Software Development Process Between Requirements and Architectures
Weaving the Software Development Process Between and s Bashar Nuseibeh Computing Department The Open University Walton Hall Milton Keynes MK7 6AA, U.K. Email:B.A.Nuseibeh@open.ac.uk ABSTRACT This position
More informationCS4507 Advanced Software Engineering
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
More informationASSESSMENT OF SOFTWARE PROCESS MODELS
ASSESSMENT OF SOFTWARE PROCESS MODELS Akhilesh Research Scholar, Department of Computer Science, Manav Bharti University, Solan (H.P.) ABSTRACT The field of software engineering is related to the development
More informationRequirements Analysis (RA): An Analytical Approach for Selecting a Software Process Models ABSTRACT
Evolving Ideas Computing, Communication and Networking Publish by Global Vision Publishing House Edited by Jeetendra Pande Nihar Ranjan Pande Deep Chandra Joshi Requirements Analysis (RA): An Analytical
More informationA Comparison between Five Models of Software Engineering
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
More informationInformation Technology Services Project Management Office Operations Guide
Information Technology Services Project Management Office Operations Guide Revised 3/31/2015 Table of Contents ABOUT US... 4 WORKFLOW... 5 PROJECT LIFECYCLE... 6 PROJECT INITIATION... 6 PROJECT PLANNING...
More informationPROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >
PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name
More informationSoftware Portfolio Analysis Does your Investment perform adequately? Mary Udeh
Software Portfolio Analysis Does your Investment perform adequately? Mary Udeh Abstract The objective of this paper is to provide a solution to the problem of escalating Information technology (IT) costs
More informationHealth Data Analytics. Data to Value For Small and Medium Healthcare organizations
Health Data Analytics Data to Value For Small and Medium Healthcare organizations HEALTH DATA ANALYTICS WHITE PAPER JULY 2013 GREENCASTLE CONSULTING Abstract This paper is targeted toward small and medium
More informationTURKEY BUSINESS ANALYSIS REPORT 2015. Thinking Like the Business
TURKEY BUSINESS ANALYSIS REPORT 2015 Thinking Like the Business CONTENT Foreword Respondent Profiles Business Partnering Business Priorities Driving Change and Innovation Efficiency of Business Analysis
More informationHow To Get A Better At Developing An Application
Whitepaper Rethink application possibilities and align to desired business outcomes EALA results January 2014 2014 Avanade Inc. All rights reserved. Executive summary It s a new world of applications.
More informationIntegrated Modeling of Business Value and Software Processes
Integrated Modeling of Business Value and Software Processes Raymond Madachy, USC Center for Software Engineering Department of Computer Science, SAL 8 University of Southern California Los Angeles, CA
More informationDiscover Viterbi: Computer Science
Discover Viterbi: Computer Science Gaurav S. Sukhatme Professor and Chairman USC Computer Science Department Meghan Balding Graduate & Professional Programs November 2, 2015 WebEx Quick Facts Will I be
More informationImproving Software Development Tracking and Estimation Inside the Cone of Uncertainty
Improving Software Development Tracking and Estimation Inside the Cone of Uncertainty Pongtip Aroonvatanaporn, Thanida Hongsongkiat, and Barry Boehm Center for Systems and Software Engineering University
More informationFAA Cloud Computing Strategy
FAA Cloud Computing Strategy Final - Version 1.0 May 2012 Federal Aviation Administration 800 Independence Avenue, SW Washington, D.C. 20591 SIGNATURE PAGE Table of Contents 1. Executive Summary... 1 2.
More informationSE464/CS446/ECE452 Software Life-Cycle and Process Models. Instructor: Krzysztof Czarnecki
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
More informationRecent Results in Software Process Modeling
Recent Results in Software Process Modeling Ray Madachy, Ph.D. C-bridge Internet Solutions University of Southern California Center for Software Engineering rmadachy@c-bridge.com, madachy@usc.edu 1 Introduction
More informationThe Blending of Traditional and Agile Project Management
1 of 6 The Blending of Traditional and Agile Project Management By Kathleen Hass Traditional project management involves very disciplined and deliberate planning and control methods. With this approach,
More informationIntegrating Risk Management into an Undergraduate Software Engineering Course
Integrating Risk Management into an Undergraduate Software Engineering Course James S. Collofello Department of Computer Science and Engineering Tempe, Arizona 85287-5406 collofello@asu.edu Andrew K. Pinkerton
More informationBest-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler
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
More informationAn Assessment between Software Development Life Cycle Models of Software Engineering
International Journal of Electronics and Computer Science Engineering 700 Available Online at www.ijecse.org ISSN- 2277-1956 An Assessment between Software Development Life Cycle Models of Software Engineering
More informationPROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL
PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL Sanja Vukićević 1, Dražen Drašković 2 1 Faculty of Organizational Sciences, University of Belgrade, vukicevicsanja@yahoo.com 2 Faculty
More informationBusiness Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM
Business Analyst Work Plan Presented by: Billie Johnson, CBAP CSM Agenda Topic Introduction Overview of a Business Analysis Work Plan Initiating a Business Analysis Effort Components of the Business Analysis
More informationA system is a set of integrated components interacting with each other to serve a common purpose.
SYSTEM DEVELOPMENT AND THE WATERFALL MODEL What is a System? (Ch. 18) A system is a set of integrated components interacting with each other to serve a common purpose. A computer-based system is a system
More informationSyllabus. REQB Certified Professional for Requirements Engineering. Foundation Level
Syllabus REQB Certified Professional for Requirements Engineering Version 2.1 2014 The copyright to this edition of the syllabus in all languages is held by the Global Association for Software Quality,
More informationUSC Price Recruitment Guide for Employers
USC Price Recruitment Guide for Employers USC Price School of Public Policy Page 1 Table of Contents Letter from the Office of Career Services 3 PriceNet 4 Overview of Employer Services 5 Internship Requirements
More informationUnderstanding Linux Migrations: How easy is it to change distributions?
Understanding Linux Migrations: How easy is it to change distributions? 1) Abstract In this paper, we look at the reality behind the perception that using Linux gives users complete flexibility to change
More informationBCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2
BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 EXAMINERS REPORT Friday 2 nd October 2015 Answer any THREE
More informationNeglecting Agile Principles and Practices: A Case Study
Neglecting Agile Principles and Practices: A Case Study Patrícia Vilain Departament de Informatics and Statistics (INE) Federal University of Santa Catarina Florianópolis, Brazil vilain@inf.ufsc.br Alexandre
More informationAbstract. 1 Introduction
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
More informationEl Camino College Industry and Technology Division Engineering Technology Department Program Review Spring 2009 Conducted by: Eric Carlson
El Camino College Industry and Technology Division Engineering Technology Department Program Review Spring 2009 Conducted by: Eric Carlson I. Overview A. Description of Program B. Status of Previous Recommendations
More information11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management?
11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 11: Managing the Software Process Project management encompasses all the
More informationOffice Office hours Email/Telephone. Monday: 8:00-9:45 or by appointment. 31-236 CHS Wednesday: 12:00-1PM or by appointment I. SYSTEMATIC EVALUATION
[Version 031816] HPM 422: PRACTICES OF EVALUATION IN HEALTH POLICY & MANAGEMENT Spring 2016, M/W- 10:00-11:50 a.m. Room 33-105, HPM 422 Moodle Site: https://ccle.ucla.edu/course/view/14s-hltpolm422-2 Faculty
More informationKeywords Software Engineering, Software cost, Universal models. Agile model, feature of software projects.
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
More informationAgile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations
www.ijcsi.org 457 Agile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations Prakash.V SenthilAnand.N Bhavani.R Assistant
More informationCSSE 372 Software Project Management: More Agile Project Management
CSSE 372 Software Project Management: More Agile Project Management Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: Plan Create a plan for
More informationTeaching Requirements through Interdisciplinary Projects
Teaching Requirements through Interdisciplinary Projects Deepti Suri, Eric Durant Department of Electrical Engineering and Computer Science Milwaukee School of Engineering 1025 North Broadway Milwaukee,
More informationThe Role of the Software Architect
IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation
More informationDeveloping New Processes for COTS- Based Systems. Lisa Brownsword, Tricia Oberndorf, and Carol A. Sledge Software Engineering Institute
focus process diversity Developing New Processes for COTS- Based Systems Although commercial off-the-shelf (COTS) products are becoming increasingly popular, little information is available on how they
More informationBuy versus Build Considerations for Clients Purchasing CLO Dashboard
Buy versus Build Considerations for Clients Purchasing CLO Dashboard Prepared by Zeroed-In Technologies for use by clients evaluating CLO Dashboard against their internal development of similar executive
More informationAccounts Payable Imaging & Workflow Automation. In-House Systems vs. Software-as-a-Service Solutions. Cost & Risk Analysis
In-House Systems vs. Software-as-a-Service Solutions Cost & Risk Analysis What is Imaging & Workflow Automation? Imaging and Workflow Automation (IWA) solutions streamline the invoice receipt-to-pay cycle
More informationCS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective:
CS 487 Week 8 Reading: 1. Ian Sommerville, Chapter 3. Objective: 1. To check the understandibility of the students in life cycle and process model for development of a software product. 2. To check if
More informationCHAPTER 1 INTRODUCTION
CHAPTER 1 INTRODUCTION 1.1 Background The command over cloud computing infrastructure is increasing with the growing demands of IT infrastructure during the changed business scenario of the 21 st Century.
More informationHamid Faridani (h.faridani@rogers.com) March 2011
Hamid Faridani (h.faridani@rogers.com) March 2011 Introduction Methodologies like Waterfall, RUP and Agile have all become key tools for software developers and project manager s to aid them in delivering
More information