Download
1 / 60
600 likes | 619 Views
PRELIM PORTION. CSCI17 SOFTWARE ENGINEERING. Module Introduction. Computer software has become a driving force. It is the engine that drives business decision making.
E N D
PRELIM PORTION CSCI17 SOFTWARE ENGINEERING
Module Introduction • Computer software has become a driving force. • It is the engine that drives business decision making. • It serves as the basis for modern scientific investigation and engineering problem solving. • It is a key factor that differentiates modern products and services. • It is embedded in systems of all kinds: transportation, medical, telecommunications, military, industrial processes, entertainment, office products, . . . the list is almost endless.
Software is virtually inescapable in a modern world. • And as we move into the twenty-first century, it will become the driver for new advances in everything from elementary education to genetic engineering • The subject covers the software development and implementation aspects of the systems development life cycle.
It introduces the concepts, theories, methods, procedures and tools needed to develop the software for computers. • Topics include: • evolutions of software, • attributes of well-engineered software, • various applications, • the software process, • and different engineering paradigms.
PRELIM MODULE Software Engineering Basic Concepts
Software’s Dual Role • Software is a product • Delivers computing potential • Produces, manages, acquires, modifies, displays, or transmits information
2. Software is a vehicle for delivering a product • Supports or directly provides system functionality • Controls other programs (e.g., an operating system) • Effects communications (e.g., networking software) • Helps build other software (e.g., software tools)
What is Software • Software is a set of items or objects that form a “configuration” that includes • programs • documents • data
Characteristics of Software in Comparison to Hardware • software is engineered • software doesn’t wear out – see figure below • software is complex
Software Applications • system software • application software • engineering/scientific software • embedded software • product-line software • WebApps (Web applications) • AI software
New Categories of Software • wireless networks • Netsourcing—the Web as a computing engine • Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) • Data mining • Grid computing • Cognitive machines • Software for nanotechnologies
Legacy Software – Why must it change? • software must be adapted to meet the needs of new computing environments or technology. • software must be enhanced to implement new business requirements. • software must be extended to make it interoperable with other more modern systems or databases. • software must be re-architected to make it viable within a network environment.
Software Myths Management Myths 1. Standards and procedures already exist for producing software. • Standards are rarely used. • Developers rarely know about them. • Standards are often out-of-date and incomplete.
2. State-of-the-art hardware is the essential element for successful software production. • Software, not hardware, tools are usually more important for achieving quality and productivity.
3. If we get behind schedule, we can always add more programmers and thus catch up. • Software development is not a mechanistic process like manufacturing. • Adding people to a late software project makes it later. This truth was first discovered by F. Brooks (The Mythical Man-Month) in 1975! • Newcomers must be educated (usually by those already working on the project) thereby reducing the amount of time spent on productive development effort.
Customer Myths 1. A general statement of objectives is sufficient to begin writing programs; details can be filled in later. • Insufficient knowledge about requirements is the major cause of failed software efforts. • Formal and detailed descriptions of data, functionality, design constraints and validation criteria are essential. • Communication between customer and developer is vital.
2. Project requirements continually change, but change can be easily accommodated because software is flexible. • The impact of change varies with the time at which it is introduced. • Early requests for change can be accommodated easily and cheaply. • Changes made during design, implementation and installation have a severe impact on cost.
Practitioner's Myths 1. Once the program is written and it works, then the job is done. • Between 50 and 70 percent of all effort expended on a program will be expended after it is delivered to the customer. 2. Until the program is running, there is no way to assess its quality. • One of the most effective software quality assurance mechanisms is the formal technical review and this can be applied from the inception of the project. 3. The only deliverable is the working program(s). • A working program is only one part of a software configuration that includes requirements and specification documents, testing information and other developmental and maintenance information.
What is Software Engineering? • Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. It is the use of sound engineering principles in order to create a software that is reliable and works efficiently
tools methods process model a “quality” focus Process, Methods and Tools • Software Engineering is a layered technology
Process • Foundation for SE • Glue that hold the technology layers together • Enables timely development of software • Framework for a set of key process areas (KPAs) developed for effective delivery of s/w engg technology. • KPA’s form the basis for management control of: • s/w projects • work products (models, data, reports, forms, etc) are produced, • milestones are established • quality is ensured • change is managed.
Methods • Provide the technical how-to’s for building software. • Include tasks that include: • Requirements analysis • Design • Program construction • Testing • Support
Tools • Provide automated/semi-automated support for the process and the methods. • When tools are integrated, information created by one tool can be used by another, creating a system for the support of software development called CASE. • CASE combines s/w, h/w and a s/w Engg database to create a S/w Engg environment.
A generic Process Framework • Engineering is the analysis , design , construction verification and management of technical entities. • Definition phase : focus on what , Identify the requirement , what is to be processed,what system behaviour is needed, what interace is to be designed,Key requirements is identified • Development Phase : focus on how, how data is constructed ,implementation of procedure s and methods • Support phase : change associated with error corrections , adaption to new s/w changes. • There are 4 types of changes • Correction , Adaptation , Enhancement ,Prevention
Software FRAME WORK Framework Activities It has 5 activities • Communication : communicate with customer and understand objectives • Planning: A map that helps in the development of software • Modeling • Analysis of requirements • Design • Construction • Code generation • Testing • Deployment : Delivery of product
Umbrella Activities • Software project management : Assess project progress against project plan • Formal technical reviews : Remove errors migrating to next activity • Software quality assurance : Define activities to ensure quality • Software configuration management : manage effect of changes in the project • Work product preparation and production • Reusability management: Define criteria for work product reuse • Measurement: define measures for meeting customer needs • Risk management : Assess risks that may affect the s/w
The Process Model:Adaptability • the framework activities will always be applied on every project ... BUT • the tasks (and degree of rigor) for each activity will vary based on: • the type of project • characteristics of the project • common sense judgment; concurrence of the project team
The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!
SOFTWARE PROCESS MODELS • A process model/ software engineering paradigm is chosen based on the nature of the project and application, the methods and tools to be used and the controls and deliverables that are required. • The different phases of a problem solving loop are: • Problem definition - identifies the specific problem to be solved • Technical Development-solves the problem through application of some technology • Solution integration- delivers the results or documents, programs, data, etc • Status quo- represents the current state of affairs
Prescriptive Process Models • Prescriptive process models advocate an orderly approach to software engineering • That leads to a few questions … • If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? • Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
Activities: • Communication : Requirements gathering • Planning : Estimate schedule • Modelling: Design • Construction : Coding and testing • Deployment : Delivery of software OR • Analysis • Design • Coding • Testing
Software Requirements Analysis • Focuses mainly on software. • To understand the nature of the program to be built, software engineer must understand information domain for software, required function, behavior, performance and interface. • Requirements for system and software are documented and reviewed with the customer.
Design: • Focuses on 4 attributes of a program: • Data structures • Software architecture • Interface representation • Procedural (algorithmic) detail • It translates the requirements into a representation of the software that can be assessed for quality before coding begins. • The design is also documented and becomes part of software configuration.
Code Generation: the design must be translated into a machine readable form and this is done in this step. • Testing: once the code has been generated, program testing begins. It ensures that all the statements have been tested. Tests are also conducted to uncover errors and ensure defined input will produce actual results. • Support: software will change after delivery. Either due to errors, the software must be changed to accommodate changes in its environment.
PROBLEMS • REAL PROJECTS RARELY FOLLOW SEQUENCE • DIFFICULT FOR CUSTOMER TO STATE ALL REQUIREMENTS EXPLICITELY • CUSTOMER MUST HAVE PATIENCE.A WORKING VERSION OF THE SOFTWARE WILL BE AVAILABLE IN LONG RUN • USED ONLY WHEN REQUIREMENTS ARE FIXED
The Prototyping Model • Customer defines a set of general objectives for software but does not identify detailed i/p, or o/p requirements. • Also a developer may be unsure of the efficiency of an algorithm, adaptability of an OS. • So for such cases this model is best. • It begins with the requirements gathering • The developer and customer meet to define overall objectives for the software, identify whatever requirements are known and outline areas where further definition is needed. • A quick design is then made which focuses on the parts of the software that are visible to the customer/user. • This leads to construction of a prototype. • This is showed to the user to make further changes if needed.
ACTIVITIES • Communication : Define overall objective ,identify requirements • Modeling and Quick plan : representation of aspects that is visible to end users • Construction of prototype : prototype is evaluated by stakeholders who provide feedback and thus enhance the product • Deployment and Delivery :
Problems • Stakeholders see what appears to be a working version of the software unaware in a rush to get it working we may have to compromise the quality • Make implementation compromises to make it working • (not suitable Os, programming language)
Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. Used when • requirements are clearly understood • project scope is constrained • creating a fully functional system in a short span of time
If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods (e.g., 60 to 90 days)[MAR91]. Used primarily for information systems applications, the RAD approach encompasses the following phases [KER94]:
Business modeling. The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it?
Data modeling. The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and the relationships between these objects .
Process modeling. The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
Application generation. RAD assumes the use of fourth generation techniques (Section 2.10). Rather than creating software using conventional third generation programming languages the RAD process works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software.
Testing and turnover. Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised.
