SEEM4570 System Design and Implementation Lecture 10 Software Development Process Software Development A software development process: A structure imposed on the development of a software product Also known as software development life cycle (SDLC) Several models proposed. Each describes an approach to a variety of tasks or activities that take place during the process. We will discuss some of these models in this lecture
Standard ISO/IEC 12207 is an international standard for software lifecycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes (the new ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes defines 43 system and software processes). ISO/IEC 12207 (1/2) Why we need standard? A standard can give a common structure and language to all buyers, suppliers, developers, maintainers, operators, managers and technicians who are involved. This common language is established in the form of well defined processes.
ISO/IEC 12207 (2/2) What is the major characteristic? The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it. So, any design principle? A basic principles: modularity. Modularity can be divided into coupling and cohesion. Coupling (1) Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are. Two common coupling terms: Loose coupling vs. tight coupling Related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand. A good software (design) should have low degree of coupling (loose coupling)!
Coupling (2) The following program has high degree of coupling. You need to understand a lot of things (e.g. database structure, connection name) that are not related to the business logic. Program 1: public function Process(){ $con = mysqli_connect("127.0.0.1","abc","123","mydb"); if (mysqli_connect_errno($con)){ die(mysqli_connect_error()); } $statement = "SELECT name, passwd FROM user"; $result = mysqli_query($con, $statement); for(; $row=mysqli_fetch_array($result); ){ processdata($row); } mysqli_close($con); } Coupling (3) The following program has low degree of coupling Program 2: public function Process(){ $con = new DBConnect(); $userdata = getuserdata($con); for(; $row=$userdata->fetch_array(); ){ processdata($row); } $con->close(); }
Coupling (4) The goals behind achieving loose coupling between classes and modules are to: Make the code easier to read. Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes. Isolate potential changes to a small area of code. Reuse classes in completely new contexts. Cohesion (1) A measure of how closely related all the responsibilities, data, and methods of a class are to each other. i.e., a measure of whether a class has a well-defined role within the system. A good software (design) should have high degree of cohesion Think about it: When you're at a loud party with a lot of different conversations going on at once, it can be difficult to focus on the one conversation you're trying to have. It's much easier to have a conversation in a quiet setting where there's only one conversation going on.
Cohesion (2) An easy test for cohesion is to look at a class and decide whether all the contents of the class are directly related to and described by the name of the class names. If the class has responsibilities that don't relate to its name, those responsibilities probably belong to a different class. If you find a subset of methods and fields that could easily be grouped separately under another class name, then maybe you should extract these methods and fields to a new class. Waterfall Model Overview The waterfall model is a sequential design process Progress is seen as flowing steadily downwards (like a waterfall) through different phases, such as requirements, design, implementation, verification, maintenance, One should move to a phase only when its preceding phase is completed and perfected. An Example
Waterfall Model Why Time spent early in the software production cycle can lead to greater economy at later stages. A simple example (idea): A bug found in the early stages (such as requirements specification or design) is cheaper in money, effort, and time, to fix than the same bug found later (such as coding). An extreme example If a program design turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design. Waterfall Model Related Concept (1) Big Design Up Front (BDUF) A software development approach in which the program s design is to be completed and perfected before that program's implementation is started
Waterfall Model Related Concept (2) Joel Spolsky, a BDUF lover: Many times, thinking things out in advance saved us serious development headaches later on. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I m proud to use it, no matter what the XP fanatics claim. They re just wrong on this point and I can t be any clearer than that. Waterfall Model Benefits Waterfall model emphasis on documentation (such as requirements documents and design documents) as well as source code. If we have less designed and documented methodologies, then in case some team members leave, knowledge may be lost and may be difficult for a project to recover. Should a fully working design document be present, new team members or even entirely new teams should be able to familiarize themselves by reading the documents.
Waterfall Model Critics (1) Poorly adaptable to changing requirements Assumes designers are able to foresee problem areas without extensive prototyping or implementation Ignore there is an overhead to be balanced between the time spent planning and the time that fixing a defect would actually cost If the cost of planning is greater than the cost of fixing then time spent planning is wasted. Waterfall Model Critics (2) It is quite impossible for many non-trivial project to finish a phase perfectly before moving to the next phase Clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. Investing a lot on planning (e.g. BDUF) is not wise
Waterfall Model Critics (3) Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems. Iterative Model Overview (1) Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between.
Iterative Model Overview (2) Develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. Iterative Model Related Concept Two kinds of famous models that implemented the concept of iterative model: Spiral Model Extreme Programming Agile Software Development Framework
Iterative Model Why Working software vs. comprehensive documentation Working software will be more useful and welcome than just presenting documents to clients in meetings Customer collaboration vs. contract negotiation Requirements cannot be fully collected at the beginning, therefore continuous customer or stakeholder involvement is very important Responding to change vs. following a plan Focus on quick responses to change and continuous development Iterative Model Benefits Suitable for certain types of environment, including small teams of experts. The customer and developers are in close communication. In water-fall model, customers are initially represented by the requirement and design documents. Documents are produced when they are required, and the content reflects the information necessary at that point in the process. All documents will not be created at the beginning of the process, nor all at the end. Like the product they define, the documents are works in progress. The idea is to have a continuous stream of products produced and available for user review
Iterative Model Critics Unstable requirements Lack of overall design specification or documentation. No documented compromises of user conflicts Inefficient in large organizations or involve a project involve many parties It is developer-centric rather than user-centric. Focuses on processes for getting requirements and developing codes and does not focus on product design Agile Development Framework Proposed by Agile Alliance in 2001. Uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Uses feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. Software developers are not coders, but experience creators
Agile Development Framework Principles Twelve principles: Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Close, daily co-operation between business people and developers Face-to-face conversation is the best form of communication Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances Agile Development Framework Concept Agile methods break tasks into small increments (known as iteration) with minimal planning and do not directly involve long-term planning. Each iteration involves: Working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, Demonstrate to stakeholders. Iterations are short time frames Typically last from one to four weeks. This minimizes overall risk and allows the project to adapt to changes quickly. An iteration might not add enough functionality to warrant a market release, but will have an available release (with minimal bugs)
Agile Development Framework Characteristics Team size is typically small (5-9 people) to simplify team communication and team collaboration. Emphasize face-to-face communication over written document Larger development efforts can be delivered by multiple teams working toward a common goal or on different parts of an effort. This might require a coordination of priorities across teams No matter what development disciplines are required, each agile team will contain a customer representative Extreme Programming Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. It advocates frequent releases in very short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
Spiral Model (1) Spiral Model (2) Combines the features of iterative model and waterfall model Allows for incremental releases of the product, or incremental refinement through each time around the spiral. Starting at the center, each turn around the spiral goes through several task regions: Determine the objectives, alternatives, and constraints on the new iteration. Evaluate alternatives and identify and resolve risk issues. Develop and verify the product for this iteration. Plan the next iteration.
Spiral Model (3) The spiral model is intended for large (e.g. few years), expensive (e.g. up to a few millions) and complicated projects (e.g. military project). Future Combat System (FCS) (2003 2009) Research/create unattended ground sensors (UGS); unmanned aerial vehicles (UAVs); unmanned ground vehicles; and eight manned ground vehicles. In 2009 Pentagon and army officials announced that the FCS effort would be swept into a new, pan-army program called the Army Brigade Combat Team Modernization Program. 2 Years an iteration