Software Development Life Cycle

The software life cycle (SLC) covers the time between product conception and end of life for the product [ieee10]. Like all engineering disciplines, engineering high quality software requires process to guide a software process through the SLC. Software engineering is “the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software” [ieee10]. Software engineers use a software development process to translate user needs into a software product that correctly and securely meets those needs [ieee10]. The process of engineering software involves several phases, which may overlap: requirements, design, implementation, test, and deployment. Software development processes are supported by practices, which are activities, maybe supported by techniques and tooling, that provide a systematic way for developers to develop software as part of a larger software development process [ieee10].

A software process model or life cycle model provides a “simplified, abstracted description of a software development process” [williams13][ieee10]. There are two high-level software development models that provide a paradigm and culture of software development: plan-driven and agile. From a software model, a specific software development process (which may also be called a _software development methodology) is created that adheres to the spirit of the model and describes the specific practices that support development for each phase. The idea of a software development model is an interface that provides behaviors associated with each major phase. Plan-driven and agile models are the abstract classes that implement the interface and provide the “spirit” of the model. The concrete software development processes are subclasses of the models and provide an interpretation of the processes involved at each phase of development and the associated practices and tools to support development when using the process. Different companies and even different groups with in the same company will adopt and/or customize a process that fits the team culture and the type of product that is under development.

Plan-driven models are typically used for projects where there are stable requirements that are known up front, like mission- or safety-critical systems. The phases of development are handled sequentially, but there may be interweaving of some phases like implementation and testing when practices like test-driven development are used. An example plan-driven development model is Team Software Process.

Agile models focus on change as a part of software development. Software is developed in short iterations, with each iteration including the standard phases of development. Agile models value interactions, collaboration, and change over strict processes, contracts, and plans. Products are typically always in a deployable state (e.g., the practice of continuous integration). An example agile development model is Scrum.

Software Development Phases

While there are many different software development processes that developers may use, there are five fundamental areas of concern, or phases, in any process: requirements, design, implementation, test, and deployment. These phases may be distinct or may be integrated depending on the specific software development process used [ieee10].

Requirements Phase

The requirements phase is “the period of time in the software life cycle during which the requirements for a software product are defined and documented” [ieee10]. Requirements define, from the customer perspective, what a software system should do or a capability that a system must have [ieee10]. Requirements are NOT a list of tasks that a developer should accomplish to create a system, but instead describe the system itself. Requirements include a description of the functionality (required behavior) and non-functional aspects of the system (how the software will do the functionality and how the system is constrained) [ieee10].

Design Phase

The design phase is “the period in the software life cycle during which definitions for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements” [ieee10].

Implementation Phase

The implementation phase is the “period of time in the software life cycle during which a software product is created from design documentation and debugged” [ieee10].

Test Phase

The test phase is “the period of time in the software life cycle during which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied” [ieee10]. While there are several different types of tests, the focus will be on unit tests and system tests. Unit tests focus on evaluation of individual methods or modules and are typically written by the developer [ieee10]. System tests evaluate a completed system to ensure that the requirements are met [ieee10].

Deployment Phase

The deployment phase is the “phase of a project in which a system is put into operation and cut over issues are resolved” [ieee10]. When software is completed, it must be deployed or delivered to the customer. Additionally, software must be maintained such that user problems are addresses after operationalization.

CSC216 Development Process and Practices

In CSC216, we follow a software development process that incorporates the phase of development described above. Our process is described in the following diagram that includes the tools that support software development practices.

Labs

The labs consist of roughly one-week iterations. A particular phase may be emphasized during a lab to meet a particular learning outcome, but you will see parts of all the phases each week. The labs will build on a common set of requirements and will incorporate work that you do as part of the Guided Projects. By the end of the semester, you will have completed the PackScheduler project. (Don’t try to start and finish it now. We haven’t covered everything you need to know to complete the project! And there are very detailed steps that you need to take to complete the project using appropriate software engineering practices!) For the labs, you will be working with one or more students and all code will be pushed to a provided GitHub repository and will be automatically evaluated by Jenkins.

Guided Projects

The Guided Projects will introduce you to the technologies and tools used for CSC216 and some of the fundamental concepts that are critical for success in the course. Each Guided Project is a one-week iterations through all the phases of software development to create the WolfScheduler. Guided Projects will combine tutorial elements with independent activities where you will apply concepts covered earlier in the project. Don’t rush through the tutorial pieces! You’ll be doing those activities independently later in the guided project! For the Guided Projects, all code will be pushed to a provided GitHub repository and will be automatically evaluated by Jenkins. Guided projects will be completed independently.

• Guided Project 1 (GP1) is a review of materials from CSC116, specifically object-oriented programming, composition, and file I/O. The new topics for GP1 are the Java Collections Framework and the course tools, specifically Eclipse, running JUnit tests, and static analysis. All test cases will be provided by the teaching staff.
• Guided Project 2 (GP2) builds on GP1 by introducing inheritance. You’ll extend the WolfScheduler project by adding an interface and abstract class to the system. You’ll continue to run provided test cases.
• Guided Project 3 (GP3) builds on GP1 and GP2 by adding the conflict checking when adding courses to a WolfScheduler schedule. For GP3, you will be writing your own unit test cases with an expectation of 80% statement coverage.

Projects

The Projects are applications of course learning outcomes in a more independent setting. Each project consists of two parts, each with their own deliverables: 1) requirements and design and 2) implementation, test, and deployment. For on-campus students, the Part 2 of Project 1 is individual, Project 2 is optional pairs, and Project 3 is required pairs. To prevent failed pairs due to lack of participation, students will only be placed on a pair for a Project Part 2 if they submit meaningful work for the Project’s Part 1.

• For Part 1 you will receive a set of use case requirements. From the requirements, you will explore a class level design of the system either by evaluating proposed designs or through the creation of your own design with supporting rationale of why you think your design would lead to a successful implementation. Additionally, you will write several black box, system test cases that will help you evaluate if your implementation of the system in Part 2 meets the requirements.
• For Part 2 you will receive a teaching staff design that you will implement and test. We provide a teaching staff design for two reasons 1) we know the design will lead to a successful implementation of the project and 2) we can provide automatic feedback, in the form of teaching staff test cases, on your progress as you work on the project that assesses how well your solution meets the provided design. You will be expected to unit test your program and achieve 80% statement coverage. Additionally, you will be expected to remove all static analysis notifications. Code will be pushed to a provided GitHub repository and will be automatically evaluated by Jenkins.

References

• [ieee10] “Systems and software engineering – vocabulary,” ISO/IEC/IEEE 24765:2010(E), pp. 1–418, Dec 2010.
• [marick97] B. Marick, “How to misuse code coverage,” 1997.
• [williams13] L. Williams, An introduction to software engineering. Amazon Digital Services LLC, 2013.
• [ahm08] N. Ayewah, D. Hovemeyer, J. D. Morgenthaler, J. Penix, and W. Pugh, “Using static analysis to find bugs,” IEEE Software, vol. 25, no. 5, pp. 22–29, Sept 2008.
• [apm07] N. Ayewah, W. Pugh, J. D. Morgenthaler, J. Penix, and Y. Zhou, “Evaluating static analysis defect warnings on production software,” in Proceedings of the 7th aCM sIGPLAN-sIGSOFT workshop on program analysis for software tools and engineering, 2007, pp. 1–8.