Presentation on theme: "CS565 Advanced Software Development Software Development Process A. O’Riordan, 2006, 2007."— Presentation transcript:
CS565 Advanced Software Development Software Development Process A. O’Riordan, 2006, 2007
Software Engineering as a Discipline the methodology, techniques and tools related to the development and management of software from conception through requirements identification, design, implementation, deployment to the final retirement. Software Engineering is relatively new field of engineering term software engineering was coined in 1967 at a NATO study group first conference held at Garmisch-Partenkirchen, Germany, 7th to 11th October 1968
An Engineering Approach software production should be an engineering-like activity up to that point software was primarily developed in an ad hoc manner - low-level assembler it is commonly perceived that the quality of software is not acceptable buggy and behind schedule not enough reuse - either code or design no rigorous measurable process
A Test-based Approach A methodology of validation and verification was called for but classical proof-based techniques developed by Dijkstra and others where proving too restricting and unwieldy. Therefore Formal proof is dispensed with, and a great effort invested instead in testing. But More mature disciples such as architecture work without large-scale testing, relying instead on careful application of design principles and good practice.
Software Crisis software crisis - Frederick Brookes, "No Silver Bullet”, Information Processing 1986. Brookes identified inherent problems associated with software production which are caused by the nature of software itself essence (unavoidable problems) and accidents (could engineer solutions to these) essence of software comprises: complexity conformity changeability invisibility.
Example: Invisibility A number of reports called into question the verifiability and “undebuggability” of large systems: Parnas’ evaluation let to his resignation from the SDI Panel on Computing in Support of Battle Management. e.g. software in not manufactured in the traditional sense what are the raw materials? how to visualize? Software is principally based on ideas, abstractions and design patterns.
Software Failure Because of the durability of this crisis, Pressman says that the software crisis should more properly be called a chronic affliction. Large-scale disasters attributed to software defects offer sober warnings: The explosion of the Ariane 5 rocket shortly after take- off Patriot missile failure during the Gulf War
Proposals to Solve Software Crisis I high-level languages compilers for languages such as Fortran, COBOL, C, etc. structured design e.g. SSADM (Structured Systems Analysis and Design) object orientation e.g. UML (Unified Modeling Language), C++, Java CASE (computer assisted software engineering) e.g. drawing tools, data dictionary quality assurance testing, ISO 9000, process maturity
Example: Software Components Most software is currently custom built, as opposed to being assembled from small encapsulated components. For example in electrical engineering, an engineer rarely builds all the circuits from scratch. Preexisting component circuits are selected offtheshelf and assembled for the new purpose. Software is moving towards this componentbased assembly as the discipline matures. Technologies such as object orientation, design patterns, etc. are leading to this type of design. Components allow reusable units to be deployed, e.g. web browser plug-ins
The Software Development Lifecycle A large software application can be seen as having the following development steps: Requirements Specification Customer and developer work together to identify actual problems for which a solution is sought - feasibility of endeavour may also be accessed System Architecture A broad system specification of What is to be done – identify major subsystems and approach Design Produce a design specification for the new system - alternative ways of satisfying the specification may be explored - this is the How
The Software Development Lifecycle II Implementation Chosen design translated into executable programs – build program code, databases, etc. System Integration The completed system is assembled and tested Maintenance Manage the day-to-day support of system operation as well as provision of any future upgrades Retirement Product replaced or removed from service
Lifecycle Models Waterfall Evolutionary Spiral simpler more complex
Characteristics of Waterfall Model Consists of a set of phases that a project progresses through in a sequential order. Each phase must be completed before the project can progress to the next phase. At the end of each phase is some form of gateway, usually a formal review where that decision is made. There is no overlap between phases.
Characteristics of Waterfall Model II It is straightforward, simple to understand and use. Deliverables are frozen at the end of each phase and serve as a baseline for the following phases. You do not see the software until the end of the project (big bang software development). Changes are not supposed to happen or are limited or are tightly controlled.
Evolutionary Model Characteristics Exploratory prototyping - Objective is to work with customers and to evolve. Applicable for small or medium-size interactive systems for parts of large systems (e.g. the user interface) for short-lifetime systems Allows you to put functional software into the hands of the customer much earlier than either the waterfall. Requires careful planning at both the project management level and the technical level.
Spiral Model Characteristics I Developed by Barry Boehm. "A Spiral Model of Software Development and Enhancement", Computer, May 1988 A risk-oriented software life cycle. Each spiral addresses major risks that have been identified. After all the risks have been addressed, the spiral model terminates as a waterfall software life cycle.
Spiral Model Characteristics II You start small, explore the risks, develop a plan to deal with the risks, and then commit to an approach for the next iteration. Each iteration involves six steps: Determine objectives, alternatives, and constraints. Identify and resolve risks. Evaluate alternatives. Develop deliverables and verify that they are correct. Plan the next iteration. Commit to an approach for the next iteration.