An Introduction to Software Engineering

What is Software?
Software is a set of items or objects that form a ³configuration´ that includes ‡ programs ‡ documents ‡ data ...

What is Software? 
 

software is engineered software doesn¶t wear out software is complex

What are the attributes of good software?  

The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. Maintainability
‡ Software must evolve to meet changing needs; Software must be trustworthy; Software should not make wasteful use of system resources; Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems. 

Dependability
‡ 

Efficiency
‡ 

Acceptability
‡

acquires.g. or transmits information Supports or directly provides system functionality Controls other programs (e. manages... modifies.Software¶s Dual Role  Software is a product ‡ ‡ Delivers computing potential Produces..g. displays. software tools)  Software is a vehicle for delivering a product ‡ ‡ ‡ ‡ . networking software) Helps build other software (e. an operating system) Effects communications (e.g.

Office. Present every where Netsourcing. Railway Reservation Engineering / Scientific Software. Expert Systems Ubiquitous Computing. Mat-Lab Embedded Software. CAD. Key Stroke . Operating Systems.Character Product . Games WebApps (Web applications Browser). Ms. Editors . Yahoo Artificial Intelligence software: Robotics . Downloading using Internet . Compilers Application Software.Line Software.The Changing Nature of Software          System Software.

‡ 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. .Legacy Software Why must it change? ‡ software must be adapted to meet the needs of new computing environments or technology.

Software Myths 

If I decide to out source the software project to the third party, I can just relax and let that firm build it.

Manage & Control If we get behind Schedule, we can add more programmers and catch up.

People can be added but only in a planned and well coordinated manner Once we write the program and get it to work, our job is done

Software should be modify (changes) at any time  

and how to reach the goal . when.Chapter 2 Process: A Generic View A Process defines who is doing what.

A Layered Technology Software Engineering tools methods process model a ³quality´ focus .

A Process Framework Process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities .

Framework Activities    Communication Planning Modeling ‡ ‡ Analysis of requirements Design Code generation Testing  Construction ‡ ‡  Deployment .

Umbrella Activities         Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management .

Deployment . 1.Generic process frame work used as a basics for the description of process models. Construction 5. Communication 2. Planning 3. Modeling 4.

THE CAPABILITY MATURITY MODEL INTERATION (CMMI) .

Specific goals [SG] establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices [SP] refine a goal into a set of process-related activities.The CMMI    The CMMI defines each process area in terms of ³specific goals´ and the ³specific practices´ required to achieve these goals. .

3.2.1.For Example: PROJECT PLANNING SG1 : Establish Estimates SP1. SP1. . Estimate the scope of the project.4. Define Project life Cycle. SP1. SP1. Establish estimates of work product and task attributes. Determine estimates of effort and cost.

1. Identify project risks SP2. Establish the budget and schedule.4.2.5. Plan for needed knowledge and skills SP2. Plan for the data management SP2. Establish the project plan .For Example: PROJECT PLANNING SG2 : Develop a project Plan SP2.6.7. Plan for the project Resources SP2.3. Plan stakeholder involvement SP2. SP2.

2. Review plans that affect the project.1.For Example: PROJECT PLANNING SG3 : Obtain commitment to the plan SP3. SP3. Obtain plan commitment . SP3. Reconcile work and resource levels.3.

Process Assessment and Improvement Soft r Process identifies modifications to is e amined identifies capa ilities and ris of oft are Process Assessment oft are Process Improvement leads to leads to apa ilit etermination motivates .

Chapter 3 Prescriptive Process Models .

‡ ‡ ‡ Prototyping The Spiral Model The Concurrent Development Model. The RAD( Rapid Application Development) Model.Prescriptive Models     The Water Fall Model. Evolutionary Process Models. . Incremental Process Model.

The Water Fall Model. . 2. The RAD( Rapid Application Development) Model.1. 3. Incremental Process Model.

The Waterfall model is the oldest paradigm for software engineering. suggests a systematic sequential approach to software development that begins with customer specification of requirements and progresses through planning .modeling.Water Fall Model   The Waterfall Model sometimes called as Classic life cycle. construction and deployment. .

The Waterfall Model Communicat ion project init iat ion require ment gat hering Planning estimating scheduling tracking Modeling analysis design Const ruct ion code t est Deployment delive ry s upport f e edba ck .

.Waterfall model phases       Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

Waterfall model problems     Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. . The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. Therefore.

As the result.Problems occurred in waterfall model     Real projects rarely follow the sequential flow. It is often difficult for the customer to state all requirements explicitly. . changes can cause confusion as the project team proceeds. A working version of the program (s) will not be available until late in the project time span. The customer must have the patience.

The Incremental Model increment # n Co m m u n i c a t i o n Plan nin g M odeling anal ys is des i gn Co n s t ru c t i o n code t es t De p l o y m e n t d e li v e ry feedback ncrement # Comm uni c a t i on Pl a nni ng M odeling analy si s des ign del er o nt h increment ¦ Co n s t ru c t i o n c ode t es t de l i v e ry feedback ncrement # Co m m u n i c a t i o n Pl a nni ng M o deling anal de del er o nd ncrement ¦ ¤ Co n s t ru c t i o n te t project calendar t ime ¤ d e l i v e ry fe e d b a c k ¦ De p l o y m e n t del er o t ncrement ¨ © § ¥ ¤ n c ode § ¥ ¤ De p l o y m e n t § ¥ ¤  ¡ ¢ £ ¡ ¢ ¡ ¡  .

Page Layout. i. iv. Advance page Layout . Editing & Document production functions. iii. Example: To develop the Word Processing Software. File Management . (Core product) ii.Incremental Process Model    The incremental model applies linear sequences in a fashion as calendar time progress. Each linear sequence produces deliverable ³increments´ of the software. Spelling & Grammar checking.

Early increments can be implemented with fewer people. If the core product is well received.Incremental Process Model    The delivery date of the project is uncertain. additional staff (if required) can be added to implement the next increment. thereby enabling partial functionality to be delivered to end-users . It might be possible to plan early increments in a way that avoids the use of hardware.

The RAD Model Team n Mode ling b u s in e s s m o d e lin g d a t a m o d e lin g p r o c e s s m o d e lin g Const ruct ion Co m m u n icat io n Team 2 c om pone nt reus e a u t o m a t ic c o d e g e n e r a t io n t e s t in g M o d e l i ng bu si ne ss m od el i ng da t a m o de l in g pro cess m o de l in g Pla n n in g Co ns t r uc t i o n D e p lo y m e n t int egrat ion deliv ery feedback Team 1 co m po ne nt reu se au t o m at i c co de ge ne rat i o n t e st i ng M o d e lin g business modeling dat a modeling process modeling Co n s t r u ct io n component reuse aut omat ic code generat ion t est ing 6 0 .9 0 d ay s .

in which rapid development is achieved by using a component based construction approach. . If requirements are well understood and the project scope is well constrained .RAD Model   RAD is the incremental software process model that emphasizes a short development cycle. The RAD model is a ³high .speed ³ adaptation of the water fall model. the RAD process enables a development team to create a ³ fully functional system´ within a short period of time.

‡ Communication works understand the business problems and information characteristics that the software must accommodate. ‡ Planning is essential because multiple software teams work in parallel on different system functions. .RAD Model  The RAD approach maps into the generic frame work activities.

‡ Data Modeling. ‡ Construction . if required. ‡ Deployment establishes a basis for subsequent iterations. ‡ Process Modeling.RAD Model  Modeling encompasses 3 major phases: ‡ Business Modeling. emphasizes the use of pre existing software components and the application of automatic code generation.

when a new application makes heavy use of new technology). 2. but scalable projects . RAD requires sufficient human resources to create the right number of RAD teams.. RAD may not be appropriate when technical risks are high( e.Problems occurred in RAD model 1. If developers and customers are not committed total the system will fail. . For large . 3.g .

. Prototyping 2. The Spiral Model 3. The Concurrent Development Model.Evolutionary Process Models 1.

Prototyping Q u ick l Quicka n Co m m u n ic at io n plan communication M o Modeling d e lin g Q u i design Quickc k d e s i g n Deployment Ddelivery & e li e r e edb feedback ack ploy nt Co n s t r u ct io n Construction of of prototype rot ot e  .

.Prototyping   A Prototyping can be used as a standalone process model. it is more commonly used a technique that can be implemented within the context of anyone of the process models. The prototyping paradigm assists the software engineer and the customer to better understand what is to be built when requirements are fuzzy.

Evolutionary Models: The Spiral planning estimation scheduling risk analysis communication modeling analysis design start deployment delivery feedback construction code test .

Evolutionary Models: Concurrent none Modelin act ivit y  chan es  nder revision aselined one       ait in nder revie #  develo ent " " ! nder re resents the st ate of a sof t are en ineerin activit y or tas    .

Still Other Process Models ‡ Component based development ‡ Commercial -off -the -Shelf ( COTS) software components . ‡ The process to apply when reuse is a development objective . can be used when software is built. developed by vendors who offer them as products .

2.Still Other Process Models ‡ Formal Methods Models² 1.Emphasizes the mathematical specification of requirements . mathematical notation. Formal Methods enable a software engineer to specify . develop and verify a computer based system by applying a rigorous .

iterative and incremental´ software process closely aligned with the Unified Modeling Language (UML)  .Still Other Process Models AOSD (Aspect Oriented Software Development) ²provides a process and methodological approach for defining. designing. specifying. and constructing aspects  Unified Process²a ³use-case driven. architecture-centric.

The Unified Process (UP) Elaborat ion elaboration Incept inception ion inception const ruct ion Releas e soft ware increment t ransit ion product ion .

UP Phases UP P ases I e ti la rati str ti ra siti Pr ti Workflows e ire e ts al sis esi I le e tati est Support It r ti n #1 #2 #n-1 #n .

Vision Document 2.Inception Phase 1. Business Model If necessary One or more prototypes . Project Plan Phases and Iterations 7. Initial project glossary 4. Initial business case 5. Initial use case model 3. Initial risk assessment 6.

functional 3. Supplementary requirements including non . Software Architecture description 5. Project Planning . Preliminary design 7. Analysis Model 4. Use case Model 2.Elaboration Phase 1. Executable architectural prototype 6. Revised risk list 8.

Elaboration Phase 8. Project Planning including Iteration plan Adapted workflow . milestones Technical work products Preliminary user manual .

Test cases 6.Construction Phase 1. Integrated software increment 4. Software components 3. Design Model 2. Test plan and procedure 5. Support documentation user manuals Installation manuals description of current increment .

Transition Phase 1. Delivered Software increment 2. Beta test Reports 3. General user feed Back .

Software Requirements .

Software Requirements      User requirements System requirements Functional and non-functional requirements Interface specification The software requirements document .

analysing.What is a requirement?    The requirements for a system are the description of the services provides by the system and its operational constraints. The process of finding out. placing an order of finding information. These reflect the needs of customers for a system that helps solve some problems such as controlling a device. documenting and checking these services and constraints is called requirements engineering (RE) .

users Client Engineers Contractor Managers System Architects User Requirements System Requirements System end.Requirements readers different types of specification Client Managers System end.users Client Engineers System developers System Architects .

 System requirements ‡ . Defines what should be implemented so may be part of a contract between client and contractor. Written for customers.Types of requirement  User requirements are statements ‡ Statements in natural language plus diagrams of the services the system provides and its operational constraints. A structured document setting out detailed descriptions of the system¶s functions. services and operational constraints.

User requirement definition 1. LIBSYS (Library Information System )shall keep track of all data required by copyright licensing agencies in the country and elsewhere. .

System Requirement Specification 1) On making a request for a document from LIBSYS. . 2) LIBSYS request forms shall be stored on the system for five years from date of request. 4) LIBSYS shall maintain a log of all requests that have been made to the system. 3) All LIBSYS request must be indexed by user. the requestor shall be presented with a form that records details of the user and the request made. the name of the material requested and by the supplier of the request.

Statements . the expected users of the software and the general approach taken by the organisation when writing the requirements. Functional user requirements may be high-level statements of ³what the system should do´ These requirements depend on the type of software being developed. of services the system should provide.Functional requirements      Describe functionality or system services. how the system should react to particular inputs and how the system should behave in particular situations. The requirements are usually describe in a fair abstract way.

Consistent ‡ There should be no conflicts or contradictions in the descriptions of the system facilities. it is impossible to produce a complete and consistent requirements document. Complete ‡ They should include descriptions of all facilities required. In practice. requirements should be both complete and consistent. .Requirements completeness and consistency     In principle.

it will not be certified as safe for operation. 2. if a real time control system fails to meet its performance requirements. failing to meet a non ± functional requirement can mean that the whole system is unusable. However . For Example : if an air craft system does not meet its reliability requirements. response time and store occupancy.1. the control functions wil not operate correctly. Non-functional requirements It is related to emergent system properties such as reliability . .

execution speed. Requirements which are a consequence of organisational policies and procedures e. reliability.Non-functional classifications  Product requirements ‡ Requirements which specify that the delivered product must behave in a particular way e. legislative requirements.  Organisational requirements ‡  External requirements ‡ . etc. process standards used. interoperability requirements.g. implementation requirements.g. etc. etc.g. Requirements which arise from factors which are external to the system and its development process e.

Functional Requirements Product Requirements Organizational Requirements External Requirements .Non-functional requirement types Non .

Product requirement types Product Requirements Usability Requirements Efficiency Requirements Reliability Requirements Portability Requirements Performance Requirements Space Requirements .

Organizational Requirement types Organizational Requirements Delivery Requirements Implementation Requirements Standards Requirements .

External requirement types External Requirements Inter Operability Requirements Implementation Requirements Ethical Requirements Legislative Requirements Privacy Requirements Safety Requirements .

.SYSTEM GOAL  The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.

Domain requirements  Requirements that come from the application domain of the system and that reflect characteristics of that domain.functional requirements . They may be a functional or Non .

. constraints on existing requirements or define specific computations. If domain requirements are not satisfied. Domain requirements be new functional requirements. the system may be unworkable.Domain requirements    Derived from the application domain and describe system characteristics and features that reflect the domain.

 Implicitness ‡ . This is often not understood by software engineers developing the system.Domain requirements problems  Understandability ‡ ‡ Requirements are expressed in the language of the application domain. Domain specialists understand the area so well that they do not think of making the domain requirements explicit.

Functional and non-functional requirements tend to be mixed-up. Several different requirements may be expressed together.  Requirements confusion ‡  Requirements amalgamation ‡ .Problems with natural language ( Requirements )  Lack of clarity ‡ Precision is difficult without making the document difficult to read.

It is NOT a design document.Software requirements document    The requirements document is the official statement of what is required of the system developers. As far as possible. it should set of WHAT the system should do rather than HOW it should do it . Should include both a definition of user requirements and a specification of the system requirements.

. Customers specify changes to the requirements Managers Use the requirements document to plan a bid for the System and to plan the system development process.Users of a requirements document System Customers Specify the requirements and read them to check that they meet their needs.

System Test Engineers Use the requirements to develop validation tests for the system .Users of a requirements document System Engineers Use the requirements to understand what system is to developed.

.Users of a requirements document System Maintenance Engineers Use the requirements to understand the system and the relationships between its parts.

IEEE requirements standard  Defines a generic structure for a requirements document that must be instantiated for each specific system. Appendices. ‡ ‡ ‡ ‡ ‡ Introduction. Specific requirements. . Index. General description.

Definitions and abbreviations. ‡ ‡ ‡ ‡ ‡ Purpose of the requirements document. .IEEE requirements standard  Introduction. References Overview of the remainder of the document. Scope of the Project.

.IEEE requirements standard  General Description ‡ ‡ ‡ ‡ ‡ Product Perspective. Assumptions and dependencies. Product Functions User Characteristics General Constraints.

IEEE requirements standard  Specific Requirements ‡ ‡ ‡ Functional & non Functional Requirements. Appendices Index .

Requirements document structure           Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index .

Non-functional requirements constrain the system being developed or the development process. Functional requirements set out services the system should provide. User requirements are high-level statements of what the system should do. tables and diagrams.Key points     Requirements set out what the system should do and define constraints on its operation and implementation. User requirements should be written using natural language. .

The IEEE standard is a useful starting point for defining more detailed specific requirements standards. A software requirements document is an agreed statement of the system requirements.    .Key points System requirements are intended to communicate the functions that the system should provide.

Sign up to vote on this title
UsefulNot useful