China
Africa
Explore chapters and articles related to this topic
Cloud DevOps
Published in Haishi Bai, Zen of Cloud, 2019
Continuous integration (CI), continuous delivery, and continuous deployment are related terms. Continuous integration is a software development process in which a new build and automated unit tests are automatically triggered whenever a developer checks in new code. This practice enables bugs to be discovered early. In some systems, a code check-in is allowed only when automated tests are passed—this is called gated check-in. Continuous delivery pushes the process further by adding automated integration tests and acceptance tests to ensure the software package remains at a production-ready quality all the time. Finally, continuous deployment automates the last step—deploy to production. With continuous deployment, every code check-in automatically goes through the entire pipeline and ends up in production. Having new versions automatically pushed to production may sound dangerous. However, statistics have shown that most deployment problems are caused by human factors. Eliminating human factors allows more frequent and more reliable deployments, which drastically shortens the customer feedback loop because customers always have access to the latest version.
Usability Testing
Published in Julie A. Jacko, The Human–Computer Interaction Handbook, 2012
One of the important forces from outside of the user experience community that has had a major impact on its practices is Agile development (Frishberg 2010). Agile development methodology grew out the frustrations that the software industry has had managing the development process. After more than 25 years of trying, software was still released later than planned, over budget, and filled with bugs. Previous to Agile, the most common approach to development was the “waterfall” method, a sequential software development process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, and maintenance. Starting about 2001, Agile development was a reaction against the waterfall model. The term “Agile” refers to a family of processes that share some common characteristics. Product requirements are addressed in a series of 2–4 week cycles by a dedicated team that is co-located. Each cycle ends with tested, working code. While code is documented, paper documents such as specifications are not part of the process.
A model-driven approach to design two assistance tools for building construction coordination
Published in Manuel Martínez, Raimar Scherer, eWork and eBusiness in Architecture, Engineering and Construction, 2020
S. Kubicki, G. Halin, J.C. Bignon, A. Guerriero, D. Hanser
Another reference in activity modeling is the Rational Unified Process (RUP) developed by Rational Software Corporation. It suggests an iterative software development process. It aims to furnish to development teams an adaptable environment guiding the collective process. The concepts of the RUP model (Kruchten 1999) are closer to those expressed above. This model is centred on processes, decomposed in stages and iterations.The process is executed by a role, concerned by artifact(s) and uses tool(s). We noted finally the guidance concept used to define guides for the user (e.g. associating a set of tools and artifacts to a process executed by a role).
Using Scrum and unified modelling language to analyze and design an automatic course scheduling system
Published in Journal of the Chinese Institute of Engineers, 2019
Ping-Shun Chen, Gary Yu-Hsin Chen, Shao-Fu Lien, Wen-Tso Huang
Conventional software development models, such as the waterfall, decompose the software development process into seven stages: systems requirements, software requirements, analysis, program design, coding, testing, and operation. Each stage is completed before the next stage begins. Conventional software development focuses on documentation; each stage requires its corresponding document. When one stage of the software development project is completed, the project team focuses on the next. Pichler and Schulze (2005) indicated that an advantage of the conventional method of information system development was that it was easily understood and applied. Conventional software development methods may be good for ideal software projects that have definite requirements (Nandhakumar 2002). However, current software development projects are usually complex, rapidly changing, and have ambiguous requirements, thereby causing project delays and increased costs. The corresponding documentation of each stage of the software development projects increases significantly, adding to the workloads on members of the software development project team. Therefore, to solve the problem of conventional software development projects, several agile software development methods have been proposed (Behutiye et al. 2017; Chow and Cao 2008; Dingsoyr et al. 2012; Dyba and Dingsoyr 2008; Hoda et al. 2017).
Agile Methodologies: Organizational Adoption Motives, Tailoring, and Performance
Published in Journal of Computer Information Systems, 2018
John F. Tripp, Deborah J. Armstrong
Organizations have various motivations when adopting a software development method. Within the information systems development domain, a software development method (also referred to as a methodology, process, or approach [12]) is a prescribed set of related, often interdependent practices, which is formulated with the intent of improved planning and execution of the software development process. Agile software development methodologies (henceforth, agile methodologies) approach the software development process using practices that allow software requirements and solutions to evolve through collaboration within self-organizing, cross-functional teams that work in short cycles (i.e., sprints) to facilitate rapid innovation [9]. Agile methodologies have become well-accepted, with over 65% of companies reporting some type of use of agile methodologies for their software development projects [3].