Software enginnering unit 01 by manoj kumar soni
- 1. A Presentation on “Software Engineering and Project Management” Course Code : IT-605 Presented by : MANOJ KUMAR SONI
- 2. SEPM…? 1. SOFTWARE : Collection of code/collection of methods/collection of Objects in a sequencing manner. 2. ENGINEERING : A technique or collection of techniques for implementing something to achieve desired goals. 3. PROJECT : A project is a temporary endeavor, having a defined beginning and end undertaken to meet unique goals and objectives. MANAGEMENT : Managing/Maintaining something.
- 3. SOFTWARE ENGINEEERING Software Engineering Is the establishment and use of Sound Engineering Principles in order to obtain economically Software that is reliable & works efficiently on real machines. (or) Software Engineering is a systematic approach to development, operation, maintenance and retirement of software.
- 4. TOOLS METHODS PROCESS A QUALITY FOCUS FIG. : SOFTWARE ENGG. LAYERS
- 5. – A discipline whose aim is the production of quality software, delivered on time, within budget, and satisfying users' needs. – The specification, development, management, and evolution of software systems. – Designing and developing high-quality software
- 6. Software Applications : S system software s application software a engineering/scientific software e embedded software e product-line software p WebApps (Web applications) WAI software
- 9. Management of software projects is different from other types of management because: Software is not tangible(clear enough). Software processes are relatively new and still “under trial” Larger software projects are usually “one-off” projects Computer technology evolves very rapidly.
- 10. MODELS 1. S/W PROCESS MODEL : Waterfall Model / Linear Sequential model / Classic Life Cycle Model. Incremental Model RAD Model 2. EVOLUTIONARY PROCESS MODEL : Prototyping Model Spiral Model WIN WIN SPIRAL MODEL The Concurrent devlopment model
- 11. Waterfall Model / Linear Sequential model / Classic Life Cycle Model.
- 12. Diagram FIG: WATERFALL MODEL
- 13. COMMUNICATION PLANNING MODELING CONSTRUCTION DEPLOYMENT FIG: WATERFALL MODEL
- 14. Waterfall Model Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing.
- 15. Waterfall Strengths Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule
- 17. When to use the Waterfall Model Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.
- 21. Incremental Model Communication SOFTWARE FUNCTIONALITY & FEATURES Increment # n Planning Modeling Construction(Code, Test) Deplyment(delivery, feeback) Delivery of n th increment Increment # 02 Delivery of 2nd increment Increment # 01 Delivery of 1st increment PROJECT CALANDAR TIME
- 22. When the elements of waterfall model are applied in iterative manner, the result is the Incremental Model. In this, the product is designed, implemented, integrated and tested as incremental builds. This model is more applicable where software requirements are well defined and basic software functionality is required early.
- 23. ADVANTAGES OF INCREMENTAL MODEL - It generates working software quickly and early during the software life cycle. - Flexibility is more and less costly. - Testing and debugging becomes easier during a smaller iteration. - Risk can be managed more easily because they can be identified easily during iteration. - Early increments can be implemented with fewer people.
- 24. DISADVANTAGES OF INCREMENTALMODEL - Each phase of an iteration is rigid (not changed) and do not overlap each other. - Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.
- 25. RAD MODEL
- 29. RAD MODEL DEPLOYMENT TEAM # N Integration, Delivery, Feedback MODELLING Business, data & process modeling CONSTRUCTION COMMUN TEAM # 2 Component reuse, ICATION MODELLING Automatic code generation, Business, data & Testing PLAN process modeling NING CONSTRUCTION TEAM # 1 Component reuse, MODELLING Automatic code generation, Business, data & Testing process modeling CONSTRUCTION Component reuse, Automatic code generation, Testing 60 to 90 Days
- 30. Advantages of the RAD methodology: Flexible and adaptable to changes. Prototyping applications gives users a tangible description from which to judge whether critical system requirements are being met by the system. Report output can be compared with existing reports. Data entry forms can be reviewed for completeness of all fields, navigation, data access (drop down lists,checkboxes, radio buttons, etc.). RAD generally incorporates short development cycles - users see the RAD product quickly. RAD involves user participation thereby increasing chances of early user community acceptance. RAD realizes an overall reduction in project risk. Pareto's 80 - 20 Rule usually results in reducing the costs to create a custom system.
- 31. Disadvantages of RAD methodology: Unknown cost of product. As mentioned above, this problem can be alleviated by the customer agreeing to a limited amount of rework in the RAD process. It may be difficult for many important users to commit the time required for success of the RAD process.
- 35. PROTOTYPING MODEL QUICK PLAN COMMUNICATION MODELING QUICK DESIGN DEPLOYTMENT DELIVERY & FEEDBACK CONSTRUCTION OF PROTOTYPE
- 38. Spiral Model
- 39. Since end-user requirements are hard to obtain/define, it is natural to develop software in an experimental way: e.g. 4. Build some software 5. See if it meets customer requirements 6. If no goto 1 else stop.
- 41. This loop approach gives rise to structured iterative lifecycle models. In 1988 Bohem developed the spiral model as an iterative model which includes risk analysis and risk management. Key idea: on each iteration identify and solve the sub-problems with the highest risk.
- 42. Spiral Model PLANING COMMUNICATION MODELING START DEPLOYMENT CONSTRUCTION
- 43. Cumulative cost Evaluate alternatives, Determine objectives, Identify & resolve risks alternatives & constraints Prototypes Operational Review & Start P1 P2 P3 Prototype commitment Requirements Concept Design, Detailed design plan Of Operation Validation Development & Verification plan Requirements validation Coding Integration & Test plan Unit & Integration Testing End Acceptance Plan next phase Develop & verify Testing next-level product
- 44. Each cycle follows a waterfall model by: 2. Determining objectives 3. Specifying constraints 4. Generating alternatives 5. Identifying risks 6. Resolving risks 7. Developing next-level product 8. Planning next cycle
- 45. Advantages n Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements n Flexible: incoporates the advantages of the waterfal and rapid prototyping methods n Comprehensive model decreases risk n Good project visibility.
- 46. Disadvantages Needs technical expertise in risk analysis to really work Model is poorly understood by non-technical management, hence not so widely used Complicated model, needs competent professional management. High administrative overhead.
- 48. What is Open Source Software (OSS) • OSS: software licensed to users with these freedoms: – to run the program for any purpose, – to study and modify the program, and – to freely redistribute copies of either the original or modified program (without royalties, etc.) • Original term: “Free software” (confused with no- price) • Other synonyms: libre sw, free-libre sw, FOSS, FLOSS • Antonyms(oposite word): proprietary software, closed software • Widely used; OSS #1 or #2 in many markets • Not non-commercial; OSS almost always commercial
- 49. what is open source software? Open Source software is distributed with its source code. The Open Source Definition has three essential features: It allows free re-distribution of the software without royalties or licensing fees to the author It requires that source code be distributed with the software or otherwise made available for no more than the cost of distribution It allows anyone to modify the software or derive other software from it, and to redistribute the modified software under the same terms.
- 50. Typical OSS development model Improvements (as source code) and Developer evaluation results: User as Developer Development Trusted Bug Reports Community Developer Trusted Sou Repository rc e Co de → Distributor “Stone soup development” User • OSS users typically use software without paying licensing fees • OSS users typically pay for training & support (competed) • OSS users are responsible for paying/developing new improvements & any evaluations that they need; often cooperate with others to do so • Goal: Active development community (like a consortium)
- 51. examples of open source software Operating Systems Linux FreeBSD, OpenBSD, and NetBSD: The BSDs are all based on the Berkeley Systems Distribution of Unix, developed at the University of California, Berkeley. Another BSD based open source project is Darwin, which is the base of Apple's Mac OS X.
- 52. examples of open source software Internet Apache, which runs over 50% of the world's web servers. BIND, the software that provides the DNS (domain name service) for the entire Internet. sendmail, the most important and widely used email transport software on the Internet. Mozilla, the open source redesign of the Netscape Browser OpenSSL is the standard for secure communication (strong encryption) over the Internet.categories.
- 53. example of open source software Programming Tools Zope, and PHP, are popular engines behind the "live content" on the World Wide Web. Languages: Perl Python Ruby Tcl/Tk
- 54. open source software sites Free Software Foundation www.fsf.org Open Source Initiative www.opensource.org Freshmeat.net SourceForge.net OSDir.com developer.BerliOS.de Bioinformatics.org see also individual project sites; e.g., www.apache.org; www.cpan.org; etc.
- 55. some dates from the history of open source 1970s: UNIX operating system developed at Bell Labs and by a diverse group of contributors outside of Bell Labs; later AT&T enforces intellectual property rights and “closes” the code 1983: Richard Stallman founds the Free Software Foundation 1993: Linus Torvalds releases first version of Linux built 1997: Debian Free Software Guidelines released
- 56. open source software development Users Documenters Users Bug reporters Patchers Maintainers Core developer(s) Users Users
- 57. open source companies IBM uses and develops Apache and Linux; created Secure Mailer and created other software on AlphaWorks Apple released core layers of Mac OS X Server as an open source BSD operating system called Darwin; open sourcing the QuickTime Streaming Server and the OpenPlay network gaming toolkit HP uses and releases products running Linux Sun uses Linux; supports some open source development efforts(Forte IDE for Java and the Mozilla web browser)
- 58. open source licensing see http://www.opensource.org/licenses/ apache software license python license ibm public license apple public source license etc.
- 59. Unified Process
- 60. Unified Process Unified Process (UP) is an attempt to draw on the best features and characteristics of conventional Software process model. The UP recognizes the importance of customer communication and streamlined methods for describing the customer's view of a system.
- 61. HISTORY During the early 1990s James Rumbaugh, Grady Booch and Iver Jacobson began working on a “Unified Method” that would combines the best features of each of their individuals methods and adopt additional features proposed by other experts. The result was UML- “Unified Modeling Language” that contains a robust notation for the modeling and development of OO (Object Oriented) systems.
- 62. UNIFIED PROCESS
- 65. Inception Elaboration Transition Construction UP Lifecycle – single phase workflow (drawn as a UML Statechart!)
- 66. Unified Process Product Management Software Lifecycle Environment * * releases Workflow Cycle Requirements Inception 4 Design Phase Elaboration Implementation Construction * Assessment Iteration Transition Deployment * Artifact
- 67. Documentation
- 68. Documentation as part of the software life cycle Programming Specifications Documentation Testing Maintenance
- 69. What is Documentation Anything written or printed Relied on as a record of proof for authorized persons Vital part of professional practice
- 70. A few questions to ask before writing Who will use the document? How will they use it? Does the documentation contain the information to help the achieve their goals?
- 71. Some quality aspects of good documentation concise complete up-to-date free of jargon well organized accurate consistent
- 72. Parts of a good user manual Table of contents (two levels if necessary) Conventions What’s new Content Appendix Index
- 74. What is a Configuration? A configuration is the “functional and physical characteristics of hardware or software” as set forth in technical documentation or achieved in a product. What is SCM? Software configuration management (SCM) is responsible to establish and maintain the integrity of the products of the software project throughout the software life cycle. This includes identifying configuration items, controlling changes and recording and reporting the change implementation status.
- 75. Configuration management Managing the products of system change Objectives: To explain the importance of software configuration management (CM) To describe key CM activities namely CM planning, change management, version management and system building Topics covered: Configuration management planning Change management Version and release management System building
- 76. Configuration management – Why New versions of software systems are created as they change For different machines/OS Offering different functionality Tailored for particular user requirements Configuration management is concerned with managing evolving software systems System change is a team activity CM aims to control the costs and effort involved in making changes to a system
- 77. Configuration management – Why Involves the development and application of procedures and standards to manage an evolving software product May be seen as part of a more general quality management process When released to CM, software systems are sometimes called baselines as they are a starting point for further development
- 78. System families PC Mainfram e version version VMS version Initial D EC Workstation system version version U nix version Sun version
- 79. Configuration management planning Starts during the early phases of the project All products of the software process may have to be managed Specifications Designs Programs Test data User manuals Thousands of separate documents may be generated for a large software system
- 80. The CM plan Defines the types of documents to be managed and a document naming scheme Defines who takes responsibility for the CM procedures and creation of “baselines” Defines policies for change control and version management Defines the CM records which must be maintained Describes the tools which should be used to assist the CM process and any limitations on their use
- 81. Symptoms of poor CM S Bugs that have been corrected reappear B Previous releases of software cannot be rebuilt P Previous releases of software cannot be found P Files get lost F Files are “mysteriously” changed F The same or similar code exists multiple times in different projects i Two developers accidentally change the same file concurrently
- 82. Configuration item identification Large projects typically produce thousands of documents which must be uniquely identified Some of these documents must be maintained for the lifetime of the software Document naming scheme should be defined so that related documents have related names. A hierarchical scheme with multi-level names is probably the most flexible approach
- 83. The configuration database All CM information should be maintained in a configuration database This should allow queries about configurations to be answered Who has a particular system version? What platform is required for a particular version? What versions are affected by a change to component X? How many reported faults in version T? The CM database should preferably be linked to the software being managed
- 84. Risk Management
- 85. What is Risk Management? The total process to identify, control, and minimize the impact of uncertain events. In IT – we focus on availability, reliability, maintainability & security In SE – we focus on quality & productivity One time, on budget & works Realistic expectations Critical, but not glamorous – Important but not urgent
- 86. Risk Management in IT context Key business functions Procurement, stock control, payroll, etc. Key business systems ERP, CRM, Data Warehousing etc. Key business infrastructure Computer systems & communication networks Mission Critical Systems – high dependency
- 87. Risk Analysis Methods Identify potential source of risk Threats, vulnerabilities & breaches Quantification of consequences Financial & non financial losses Assessment of likelihood of occurring Annual loss expectation (ALE) Mitigation strategies Insurance, procedures, back-ups
- 88. Threats, Vulnerabilities & Breaches Threat Potential for an event to occur having adverse consequences Vulnerability A weakness in a system which increases the likelihood of a failure (e.g. security breach) Breach/Failure Exploitation of a vulnerability yielding unauthorised access to a system or failure
- 89. Risk Identification Threats Natural disasters (fire, flood, lightning…) Infrastructure failures (blackouts, head crash, communications outage…) Software defects (buffer overflows…) Government policies (ban on SPAM/Porn) Intruders & illegitimate use (hacking, sniffing…) Human limitation (user errors, staff shortages…)
- 90. Risk Identification Vulnerabilities Software defects (no audit trail, poor documentation, poor version control, insufficient testing…) Hardware failure (MTBFs) Design weakness (open protocols, spoofing…) Human behaviour (security awareness, social engineering, recruitment procedures…)
- 91. Risk Identification Example of Social Engineering
- 92. Risk Identification Breaches Michelangelo virus ‘I Love You’ virus ‘Good Times’ hoax Kevin Mitnick Failures Head crash Staff absence
- 93. Four Facets of Security 1. Confidentiality Access control, unobservability, Anonymity 2. Integrity Physical integrity, rollback, separation of duties 3. Availability Containment, robustness, recovery 4. Accountability Audit, id & authentication, trusted path…
- 94. Security Control Techniques Physical security Access control, intrusion detection, monitoring Logical security Accountability, least privilege, separation of powers, default security, cryptography, audits Disaster Recovery Plans Id risks, assess impact, plan recovery, test Backup Strategies Loss tolerance, target data, media rotation, test
- 95. Questions?