The Software Development Process (SDLC)

Total Page:16

File Type:pdf, Size:1020Kb

The Software Development Process (SDLC) http://home.hit.no/~hansha/?page=software_development poke.com - and - The Software http://geek Development . Available: Process geek&poke (SDLC) O. Widder. (2013). Hans-Petter Halvorsen IT System B. Lund. (2013). Lunch. Available: http://www.lunchstriper.no, http://www.dagbladet.no/tegneserie/lunch/ Planning Deployment Maintenance Testing The Software Development Requirements Lifecycle Analysis (SDLC) Implementation Design 4 5 The Development Process The Development Process involves different phases, e.g.: In this case the overall Requirements are given by the Teacher in the The Requirements may be Assignment. given by the Customer Requirements The details are written by you! Design The Design phase is important, but make sure you have time left for all the other tasks as Are the Design wrong? Go well) back and correct it! Implementation Errors? Improve your code and fix the bugs Testing Make sure everything work as expected When you are finished, you deploy and test the solution Deployment on the Customer Site 6 Functionality Requirements Initial User Interface Planning Technology Platform Selection Technical Architecture Support Requirements Installation Project Plan Application Architecure Detailed Specifications System Interface Deployment/ Design Maintenance Design Deployment Finalize User Interface Acceptance Test Plans Testing Application Code Development System Testing Testing Implementation System Interface Development Unit Testing RegressionTesting Integration Testing Integration with existing Apps O. Widder. (2013). geek&poke. Available: http://geek-and-poke.com 8 Software Releases Start Alpha Release Beta Releases RC (Release Candidate) RTM (Release To Manufacturing) Finished Note! other terms are also used 9 Software Releases Before the software is released • Alpha Release(s) (Internal release, not public) • Beta Release(s) (“Developer Preview”, “Consumer Preview”) • RC - Release Candidate(s) (“Release Preview”) • RTM – Release To Manufactoring Maintenance (after the software is released) • Patches (small fixes) • SP - Service Packs (lots of small fixes and pathes bundle together), SP1, SP2, R1, R2, .. … Start Planning next Release 10 Teams and Roles Customer/Stakeholders • Customer/Stakeholders • Project Manager • Software Architect Collaboration! • Software Designer • Developer Software Architect Software Tester • Tester • etc. Project Manager Software Designer Programmer 11 Software Teams 12 Software Team Stakeholders Project Manager Software Tester UX Designer System Engineer Programmer Software Architect A System Engineer is a general person that could be a Programmer, Architect, Designer, Tester in different phases in the project, or he could be a tester in one project and a programmer in another project – all in one person. That is usually the case in small companies, while in larger companies these roles (designer, tester, programmer) could be a full-time job. Project Planning and Management Project Planning Tools: Gantt Chart, Backlog, Task Board, Burn Down Chart, etc. B. Lund. (2013). Lunch. Available: http://www.lunchstriper.no, http://www.dagbladet.no/tegneserie/lunch/ 14 How to work in the project period Project Working with Documentation Management Project Tasks (Report, etc.) Start Finish Important: Work with these activities in parallel!!! 15 Brainstorming/Kick Off A Project should always start with a Brainstorming • Involve all in the group • Discuss what you are going to do in the project • How are you going to solve the project? • etc. 16 Deadlines As a software developer you need to deal with lots of deadlines during the software project! Proper Project Planning and Management makes it easier to fulfill these deadlines 17 Software Phases Hans-Petter Halvorsen Software Phases Requirements Deployment Design Testing Implementation Software Development Process – Requirements & Design • The Requirements is normally given by the Customer • SRS – Software Requirements Specification document Software Requirements & Design Requirements (WHAT): • WHAT the system should do • Describe what the system should do with Words and Figures,etc. • SRS – Software Requirements Specification Software Design (HOW): • HOW it should do it • Examples: GUI Design, UML, ER diagram, CAD, etc. • SDD – Software Design Document Many dont separate SRS and SDD documents, but include everything in a Requirements document. In practice, requirements and design are inseparable. Software Development Process - Design How the Software will work • Technical Design (Platform, Architecture, etc.) • UX Design (User eXperience, GUI/HMI) 22 Software Development Process Requirements Plan what you are going to do Design Implementation before you actually do it • Make sure to have the Design ready before you start the Implementation (Coding) • Flow Charts, UML, Database Modelling, etc. • Create Detailed Requirements • GUI/HMI – Start by designing your GUI on the “paper” 23 Software Development Process - Testing Document Test Planning Tests Perform Tests Results 24 Software Development Process - Testing Always test your application! • Test it yourself • Test it on other computers and environments • Make sure others test your application • Eat Your Own Dog Food 25 Software Development Process - Deployment Software deployment is all of the activities that make a software system available for use. • Make sure the Software is well tested • The Software should be easy to install 26 Software Development Methods/Processes How we approach the different phases in software development (Requirements, Design, Implementation, Testing, Deployment) differ depending on what kind of Software Development method we choose. A short overview of the most used/known methods are given on the next slides. Hans-Petter Halvorsen Software Development Methods • Waterfall model • Spiral model • V model • Iterative and Incremental development • Rapid application development (RAD) • Test Driven Development (TDD) • Agile development – eXtreme Programming (XP) – Scrum (the most popular Agile method) • Lean software development • Kanban • etc. 28 29 Software Development Methods Traditional Plan-driven Agile Methods Methods eXtreme Programming Scrum V-Model Waterfall (XP) Method Lean Software Feature Driven Development Development (FDD) Test Driven Kanban Spiral model Development (TDD) 30 Software Development Methods Traditional Plan-driven Methods Agile Methods eXtreme Programming (XP) Waterfall Method Scrum Feature Driven Development (FDD) V-Model Test Driven Development (TDD) Spiral model Lean Software Development Kanban Even if we use different software development methods, we deal with the same phases like Requirements, Design, Coding, Testing and Deployment – but they may have different priority and may be done in different manners and order, etc. 31 Plan-driven vs. Agile Plan-based development Requirements Requirements Design and engineering specification implementation Requirements change requests Agile development Requirements Design and engineering implementation I. Sommerville, Software Engineering: Pearson, 2010. 32 Waterfall method • Sequential process • The Phases Requirements, Design, Implementation, Testing, Deployment and Maintenance poke.com - need to be followed in that order. and - • In a strict Waterfall model, after each phase is finished, it proceeds to the next one. http://geek • Cons: – impossible for any non-trivial project to finish a phase of a . Available: software product's lifecycle perfectly before moving to the next phases geek&poke – For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it O. Widder. (2013). 33 The Waterfall Model Planning to create a new Software Finished Requirement A Sequential Process Finished Not Finished? -Go back and Fixit! Design Finished Not Finished? Implementation -Go back and Fixit! Finished Not Finished? -Go back and Fixit! Testing You cannot go to next phase before Deployment Not Finished? finsihed the previous phase -Go back and Fixit! Maintenance Software Finished V-model 35 V-model • An extension of the waterfall model • More flexible • “The V-Model reflects a project management view of software development and fits the needs of project managers, accountants and lawyers rather than software developers or users.” 36 Spiral model 37 Spiral model • Some key aspecta from Waterfall and RAD • Iterative risk analysis • Suitable for large-scale complex systems 38 Agile Software Development Hans-Petter Halvorsen 40 Agile • A group of software development methods • Iterative approach • Self-organizing and cross-functional Teams Examples: • eXtreme Programming (XP) • Scrum • Kanban 41 Agile Focus on Programmig Focus on Process XP Timebox-based Flow-based Scrum Kanban 42 Scrum Daily Scrum Meetings Sprint Review 43 Scrum • A Framework for Software Development • Agile Software Development method • Simple to understand • Flexible • Exremely difficult to master! • Self-organizing Teams (3-9 persons) • Scrum Team: – Product Owner – Scrum Master – Development Team 44 Kanban • Kanban is based on Lean and Toyota production priciples – Just-in-Time principle • Kanban has fewer “rules” than scrum • Kanban is flow-based, while Scrum is Timebox- based (Sprints) • Limit WIP (Work in Progress) • Less focus on Esitmation 45 Kanban board (Task board) https://kanbanflow.com Similiar to the Taskboard used in Scrum 46 eXreme Programming (XP) • An Agile method • Pair Programming • Code Reviews • Unit Testing • Standup Meetings 47 eXreme Programming (XP) 48 TDD 49 Finally…
Recommended publications
  • Towards an Application Lifecycle Management Framework
    VTT CREATES BUSINESS FROM TECHNOLOGY Technology and market foresight • Strategic research • Product and service development • IPR and licensing Dissertation VTT PUBLICATIONS 759 • Assessments, testing, inspection, certification • Technology and innovation management • Technology partnership • • • VTT PUBLICATIONS 759 TOWARDS AN APPLICATION LIFECYCLE MANAGEMENT FRAMEWORK AN APPLICATION 759 TOWARDS • VTT PUBLICATIONS VTT PUBLICATIONS 742 Elina Mattila. Design and evaluation of a mobile phone diary for personal health management. 2010. 83 p. + app. 48 p. 743 Jaakko Paasi & Pasi Valkokari (eds.). Elucidating the fuzzy front end – Experiences from the INNORISK project. 2010. 161 p. 744 Marja Vilkman. Structural investigations and processing of electronically and protonically conducting polymers. 2010. 62 p. + app. 27 p. 745 Juuso Olkkonen. Finite difference time domain studies on sub-wavelength aperture structures. 2010. 76 p. + app. 52 p. 746 Jarkko Kuusijärvi. Interactive visualization of quality Variability at run-time. 2010. 111 p. 747 Eija Rintala. Effects of oxygen provision on the physiology of baker’s yeast Saccharomyces cerevisiae. 2010. 82 p. + app. 93 p. 748 Virve Vidgren. Maltose and maltotriose transport into ale and lager brewer’s yeast strains. 2010. 93 p. + app. 65 p. 749 Toni Ahonen, Markku Reunanen & Ville Ojanen (eds.). Customer value driven service business development. Outcomes from the Fleet Asset Management Project. 2010. 43 p. + app. 92 p. 750 Tiina Apilo. A model for corporate renewal. Requirements for innovation management. 2010. 167 p. + app. 16 p. 751 Sakari Stenudd. Using machine learning in the adaptive control of a smart environment. 2010. 75 p. 752 Evanthia Monogioudi. Enzymatic Cross-linking of ββ-casein and its impact on digestibility and allergenicity.
    [Show full text]
  • Devsecops in Reguated Industries Capgemini Template.Indd
    DEVSECOPS IN REGULATED INDUSTRIES ACCELERATING SOFTWARE RELIABILITY & COMPLIANCE TABLE OF CONTENTS 03... Executive Summary 04... Introduction 07... Impediments to DevSecOps Adoption 10... Playbook for DevSecOps Adoption 19... Conclusion EXECUTIVE SUMMARY DevOps practices enable rapid product engineering delivery and operations, particularly by agile teams using lean practices. There is an evolution from DevOps to DevSecOps, which is at the intersection of development, operations, and security. Security cannot be added after product development is complete and security testing cannot be done as a once-per-release cycle activity. Shifting security Left implies integration of security at all stages of the Software Development Life Cycle (SDLC). Adoption of DevSecOps practices enables faster, more reliable and more secure software. While DevSecOps emerged from Internet and software companies, it can benefit other industries, including regulated and high security environments. This whitepaper covers how incorporating DevSecOps in regulated Industries can accelerate software delivery, reducing the time from code change to production deployment or release while reducing security risks. This whitepaper defines a playbook for DevSecOps goals, addresses challenges, and discusses evolving workflows in DevSecOps, including cloud, agile, application modernization and digital transformation. Bi-directional requirement traceability, document generation and security tests should be part of the CI/CD pipeline. Regulated industries can securely move away
    [Show full text]
  • CADET: Debugging and Fixing Misconfigurations Using Counterfactual Reasoning
    CADET: Debugging and Fixing Misconfigurations using Counterfactual Reasoning Md Shahriar Iqbal∗ Rahul Krishna∗ Mohammad Ali Javidian University of South Carolina Columbia University Purdue University [email protected] [email protected] [email protected] Baishakhi Ray Pooyan Jamshidi Columbia University University of South Carolina [email protected] [email protected] Abstract Swap Mem. Swap Memory Modern computing platforms are highly-configurable with thou- sands of interacting configuration options. However, configuring GPU Resource these systems is challenging and misconfigurations can cause un- 512 Mb Latency 1Gb Memory Pressure expected non-functional faults. This paper proposes CADET (short 2Gb 3Gb for Causal Debugging Toolkit) that enables users to identify, ex- 4Gb Latency plain, and fix the root cause of non-functional faults early and in a GPU Growth GPU Growth principled fashion. CADET builds a causal model by observing the (a) (b) (c) performance of the system under different configurations. Then, it uses casual path extraction followed by counterfactual reason- Figure 1: Observational data (in Fig.1a) (incorrectly) shows ing over the causal model to (a) identify the root causes of non- that high GPU memory growth leads to high latency. The trend functional faults, (b) estimate the effects of various configuration is reversed when the data is segregated by swap memory. options on the performance objective(s), and (c) prescribe candi- date repairs to the relevant configuration options to fix the non- functional fault. We evaluated CADET on 5 highly-configurable systems by comparing with state-of-the-art configuration optimiza- heat dissipation [15, 71, 74, 84]. The sheer number of modalities tion and ML-based debugging approaches.
    [Show full text]
  • Enterprise Application Lifecycle Management Solutions Enterprise Application Lifecycle Management Solutions
    Enterprise Application Lifecycle Management Solutions Enterprise Application Lifecycle Management Solutions This extensive onsite knowledge gained from years of expe- Products and Solutions for rience combined with our trusted relationships with end- users, puts us in a unique position to self-instrument the Comprehensive Enterprise products crucially needed by our customers to successfully accomplish their Enterprise Application Lifecycle Manage- Application Lifecycle ment projects. Management With this in mind, we have developed Our Enterprise Application Lifecycle Ma- RaySuite. nagement Solutions include delivering RaySuite is a comprehensive set of products that automates various tasks within an Enterprise Application Lifecycle. consulting and software packaging ser- vices to enterprises undergoing an OS This automation ranges from the analysis of the existing application portfolio and license inventories via complex migration or implementing a software license management and software packaging, all the way deployment tool. We have successfully to comprehensive quality control and fi nally software deployment in production. These automated processes served over 600 enterprise customers are sustainable and can be replicated for every change and with excellent results. every patch. A central database and a common user interface found throughout all RaySuite products form a consistent solution and off er a strong contrast to existing patchwork solutions that are often found in enterprises, as a result of limited vision and the implementation of various suppliers. Al- though Raynet guarantees a consistent approach with the use of its entire product range, it is still possible to buy and implement the individual products of RaySuite autono- mously as well as integrate them with existing third-party or home-grown products.
    [Show full text]
  • Automatic Deployment of Distributed Software Systems: Definitions and State of the Art
    Open Archive TOULOUSE Archive Ouverte (OATAO) OATAO is an open access repository that collects the work of Toulouse researchers and makes it freely available over the web where possible. This is an author-deposited version published in : http://oatao.univ-toulouse.fr/ Eprints ID : 14816 To link to this article : DOI :10.1016/j.jss.2015.01.040 URL : http://dx.doi.org/10.1016/j.jss.2015.01.040 To cite this version : Arcangeli, Jean-Paul and Boujbel, Raja and Leriche, Sébastien Automatic Deployment of Distributed Software Systems: Definitions and State of the Art. (2015) Journal of Systems and Software, vol. 103. pp. 198-218. ISSN 0164-1212 Any correspondance concerning this service should be sent to the repository administrator: [email protected] Automatic deployment of distributed software systems: Definitions and state of the art a, a b Jean-Paul Arcangeli ∗, Raja Boujbel , Sébastien Leriche a Université de Toulouse, UPS, IRIT, 118 Route de Narbonne, F-31062 Toulouse, France b Université de Toulouse, ENAC, 7 Avenue Édouard Belin, F-31055 Toulouse, France a b s t r a c t Deployment of software systems is a complex post-production process that consists in making software available for use and then keeping it operational. It must deal with constraints concerning both the system and the target machine(s), in particular their distribution, heterogeneity and dynamics, and satisfy requirements from different stakeholders. In the context of mobility and openness, deployment must react to the instability of the network of machines (failures, connections, disconnections, variations in the quality of the resources, etc.).
    [Show full text]
  • Devops Point of View an Enterprise Architecture Perspective
    DevOps Point of View An Enterprise Architecture perspective Amsterdam, 2020 Management summary “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”1 Setting the scene Goal of this Point of View In the current world of IT and the development of This point of view aims to create awareness around the IT-related products or services, companies from transformation towards the DevOps way of working, to enterprise level to smaller sizes are starting to help gain understanding what DevOps is, why you need it use the DevOps processes and methods as a part and what is needed to implement DevOps. of their day-to-day organization process. The goal is to reduce the time involved in all the An Enterprise Architecture perspective software development phases, to achieve greater Even though it is DevOps from an Enterprise Architecture application stability and faster development service line perspective, this material has been gathered cycles. from our experiences with customers, combined with However not only on the technical side of the knowledge from subject matter experts and theory from organization is DevOps changing the playing within and outside Deloitte. field, also an organizational change that involves merging development and operations teams is Targeted audience required with an hint of cultural changes. And last but not least the skillset of all people It is specifically for the people within Deloitte that want to involved is changing. use this as an accelerator for conversations and proposals & to get in contact with the people who have performed these type of projects.
    [Show full text]
  • ASSESSING KANBAN FITMENT in the FLUID and FAST-PACED WORLD of SOFTWARE DEVELOPMENT - Vikram Abrol, Ketan Shah
    WHITE PAPER ASSESSING KANBAN FITMENT IN THE FLUID AND FAST-PACED WORLD OF SOFTWARE DEVELOPMENT - Vikram Abrol, Ketan Shah. Abstract Operating in a business environment governed by speed and agility, IT companies are under constant and immense pressure to reduce time-to-market and enhance product quality. The birth of the Agile approach and models like Scrum owe their existence to this need driving managers to find better solutions. Looking to achieve a faster and more efficient software development cycle (SDC), IT companies have adopted certain methodologies, such as the Lean approach, from the manufacturing industry – another business where speed and efficiency hold the key to profitability. The concept of Kanban also originated in the manufacturing space and has filtered into the IT industry several years ago as an effective approach to manage SDC. The terminology related to Kanban in manufacturing context comes mostly from Toyota Motor Corporation in Japan where the system was invented. The Japanese term Kanban literally means a visual card or a signboard. Hence the Kanban system of work management essentially focuses on visualizing the workflow in order to reduce constraints and minimize the work-in- progress (WIP). External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Kanban in the context of software development The term Kanban can take on different A Japanese word for visual sign or nuances in the contexts of manufacturing billboard process and IT software development. Toyota production line staff used a Kanban A Learn system to – an actual card – as an inventory control control production cue in their manufacturing process and based on demand - inspired by implemented Just in Time (JIT) production What Toyota methodology to reduce idle inventory is Kanban and WIP stretches.
    [Show full text]
  • Code Debugging Tool to Help Teach Mainframe Programming Languages Claudio Gonçalves Bernardo Paulo Roberto Chineara Batuta Msc
    Code Debugging Tool to Help Teach Mainframe Programming Languages Claudio Gonçalves Bernardo Paulo Roberto Chineara Batuta MSc. Computer Engineer MBA Software Quality Universidade Paulista Centro Universitário Araraquara Brazilia – Brazil São Paulo - Brazil [email protected] [email protected] Abstract – The purpose of testing activity is to discover errors in important to check the quality of software at various stages of software and for this objective to be achieved many activities development, not only restricting the testing phase of the software. must be performed. There are several types of test and while An appropriate test is one that discovers the greatest possible some are generated and focused on functional verification of a number of faults in the software and when this software is designed component and incorporating components in the structure of the to run in an large environment, also known as Mainframe, becomes program, others are applied to point traceability requirements. an even greater difficulty, since this environment is complex and the There are systems tests designed to validate part of a software characteristics of each facility are different. Universities see this component, which is a part of software solution greater. Its difficulty as a major obstacle to the teaching of languages such as function is only to be a small part of a more complex reality. The Cobol, PL/I, Easytrieve, Assembler and others, who did not die and different types of tests are complementary and in most cases are will not die, as a single system mainframe can deliver thousands of applicable to all software developed. All aim to develop programs virtual Linux platforms with a small fraction the dollar cost, power with the fewest mistakes as possible, allowing the product to and space [20].
    [Show full text]
  • Lean Thinking in Software Development: Impacts of Kanban on Projects
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Helsingin yliopiston digitaalinen arkisto Department of Computer Science Series of Publications A Report A-2011-4 Lean Thinking in Software Development: Impacts of Kanban on Projects Marko Ikonen To be presented, with the permission of the Faculty of Science of the University of Helsinki, for public criticism in Auditorium XII, University Main Building, on 19th December 2011, at noon. University of Helsinki Finland Supervisors Professor Pekka Abrahamsson (University of Helsinki, Finland) Professor Jukka Paakki (University of Helsinki, Finland) Pre-examiners Professor Giancarlo Succi (Free University of Bolzano-Bozen, Italy) Professor Juan Garbajosa (Technical University of Madrid, Spain) Opponent Professor Markku Oivo (University of Oulu, Finland) Custos Professor Pekka Abrahamsson (University of Helsinki, Finland) Contact information Department of Computer Science P.O. Box 68 (Gustaf H¨allstr¨omin katu 2b) FI-00014 University of Helsinki Finland Email address: [email protected].fi URL: http://www.cs.Helsinki.fi/ Telephone: +358 9 1911, telefax: +358 9 191 51120 Copyright c 2011 Marko Ikonen ISSN 1238-8645 ISBN 978-952-10-7409-7 (paperback) ISBN 978-952-10-7410-3 (PDF) Computing Reviews (1998) Classification: D.2.9, K.6.3 Helsinki 2011 Unigrafia Lean Thinking in Software Development: Impacts of Kanban on Projects Marko Ikonen Department of Computer Science P.O. Box 68, FI-00014 University of Helsinki, Finland [email protected].fi http://www.cs.helsinki.fi/u/mjikonen/ PhD Thesis, Series of Publications A, Report A-2011-4 Helsinki, December 2011, 104+90 pages ISSN 1238-8645 ISBN 978-952-10-7409-7 (paperback) ISBN 978-952-10-7410-3 (PDF) Abstract The history of software development in a somewhat systematical way has been performed for half a century.
    [Show full text]
  • Getting Started with the Salesforce® Agile Accelerator
    Getting Started with the Salesforce® Agile Accelerator Salesforce, Summer ’16 @salesforcedocs Last updated: April 14, 2016 © Copyright 2000–2016 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of salesforce.com, inc., as are other names and marks. Other marks appearing herein may be trademarks of their respective owners. CONTENTS SALESFORCE AGILE ACCELERATOR . 1 WHAT’S NEW WITH SALESFORCE AGILE ACCELERATOR . 2 INSTALL SALESFORCE® AGILE ACCELERATOR . 3 ASSIGN A DEFAULT PERMISSION SET . 4 PERMISSION SETS DETAIL . 5 CREATE AND MANAGE TEAMS . 7 SALESFORCE PRODUCT TAG OVERVIEW . 8 CREATE PRODUCT TAGS . 9 CREATE YOUR FIRST SPRINT . 10 SALESFORCE EPICS . 12 SALESFORCE THEMES . 14 CREATE A WORK RECORD . 15 RELATE A CASE TO A WORK RECORD . 17 CREATE A TASK . 19 VIEW YOUR BACKLOG MANAGER . 21 PANEL TYPES AND CRITERIA . 23 CUSTOM PICKLIST VALUES FOR WORK RECORDS . 24 CUSTOM FIELDS FOR WORK RECORDS . 26 CUSTOM FIELDS FOR PRODUCT TAGS . 28 Contents CONFIGURE COMMUNITIES . 30 CREATE USER STORIES AND BUGS IN SALESFORCE1 . 32 CONFIGURE EMAIL VOLUME . 34 CONFIGURE THE EMAIL2AGILE SERVICE . 35 USE THE QUICK CREATE WORK RECORD GOOGLE CHROME EXTENSION . 36 KANBAN . 38 What is Kanban? . 38 Create a Kanban Board . 39 Edit a Kanban Column . 40 Manage Your Kanban Backlog . 41 Customize Kanban Cards . 43 SALESFORCE AGILE ACCELERATOR ® Salesforce Agile Accelerator helps you manage your agile product development with the same EDITIONS technology that’s used in your Salesforce organization. Your entire team can track user stories, bugs, reports, and more from within Salesforce. For added flexibility, Kanban is supported. Use it together Available in: Salesforce with Scrum, or by itself.
    [Show full text]
  • Radiant Info School Project Management Project Management
    Radiant info school Project Management Project Management Life Cycle Managing your digital media project is one of the most important and often overlooked aspects of the development process. You will find that effort you put into planning, scheduling, and organizing your project will pay off enormously. Here we'll outline some proven techniques for planning, scheduling, and completing your project. A project has five phases. Here's a brief summary of each: . Initiation Articulate your vision for the project, establish goals, assemble your team, and define expectations and the scope of your project. Develop a Business Case Undertake a Feasibility Study Establish the Project Charter It will help you to define the scope of your project. Writing the Project Charter is typically one of the most challenging steps in the Project Life Cycle, as it defines the parameters within which the project must be delivered. It sets out the project vision, objectives, scope and implementation, thereby giving the team clear boundaries within which the project must be delivered. Appoint the Project Team Set up the Project Office Perform Phase Review Radiant info school Project Management . Planning Refine the scope, identify specific tasks and activities to be completed, and develop a schedule and budget. Create a Project Plan Create a Resource Plan Create a Financial Plan Create a Quality Plan Create a Risk Plan Create an Acceptance Plan Create a Communications Plan Create a Procurement Plan Contract the Suppliers Define the Tender Process Issue a Statement of Work Issue a Request for Information Issue a Request for Proposal Create Supplier Contract Perform Phase Review execution Build Deliverables Monitor and Control Perform Time Management Perform Cost Management Perform Quality Management Perform Change Management This process helps you to manage all requests for change within your project.
    [Show full text]
  • Planning in Software Project Management
    PLANNING IN SOFTWARE PROJECT MANAGEMENT AN EMPIRICAL RESEARCH OF SOFTWARE COMPANIES IN VIETNAM Thesis presented to the Faculty of Economics and Social Sciences at the University of Fribourg (Switzerland) in fulfillment of the requirements for the degree of Doctor of Economics and Social Sciences by Quynh Mai NGUYEN from Vietnam Accepted by the Faculty of Economics and Social Sciences on May 30th, 2006 at the proposal of Professor Dr. Andreas Meier (first advisor) Professor Dr. Jacques Pasquier (second advisor) Professor Dr. Laurent Donzé (third advisor) Fribourg, Switzerland 2006 The Faculty of Economics and Soci al Sciences at the University of Fribourg neither approves nor disapproves the opinions expressed in a doctoral dissertati on. They are to be considered those of the author (decision of the Faculty Council of January 23rd, 1990). To my parents, and To Phuong and Trung, my children ACKNOWLEDGEMENT I would like to express my extreme gratitude to Prof. Dr. Andreas Meier for his guidance, encouragement and helpful supervision during the process of this thesis. I would like to thank Prof. Jacques Pasquier and Prof. Laurent Donzé for their review and comments. My special thanks also go to Dr. Fredric William Swierczek for his invaluable help, advices and suggestions for improvement. Without their help and advice this dissertation could not be completed. I would like to thank my friends, Dr. Bui Nguyen Hung, and Dr. Nguyen Dac Hoa, Mrs. Nguyen Thuy Quynh Loan for their assistance and helpful suggestions and contributions. I would like to thank the government of Switzerland and the Swiss – AIT – Vietnam Management Development Program (SAV) for giving me the scholarship for this PhD program.
    [Show full text]