Software enginnering unit 01 by manoj kumar soni


Published on

Software enginnering unit 01 by manoj kumar soni.....RGPV

Published in: Education, Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software enginnering unit 01 by manoj kumar soni

  1. 1. A Presentation on“Software Engineering and Project Management” Course Code : IT-605 Presented by : MANOJ KUMAR SONI
  2. 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. 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.
  5. 5. – A discipline whose aim is the production ofquality software, delivered on time, withinbudget, and satisfying users needs.– The specification, development, management,and evolution of software systems.– Designing and developing high-qualitysoftware
  6. 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
  7. 7. 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.
  8. 8. MODELS1. S/W PROCESS MODEL : Waterfall Model / Linear Sequential model / Classic Life Cycle Model. Incremental Model RAD Model2. EVOLUTIONARY PROCESS MODEL : Prototyping Model Spiral Model WIN WIN SPIRAL MODEL The Concurrent devlopment model
  9. 9. Waterfall Model / Linear Sequential model / Classic Life Cycle Model.
  10. 10. Diagram FIG: WATERFALL MODEL
  12. 12. 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.
  13. 13. 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
  14. 14. 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.
  15. 15. Incremental Model
  16. 16. Incremental Model CommunicationSOFTWARE 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
  17. 17. When the elements of waterfall model areapplied in iterative manner, the result is theIncremental Model. In this, the product isdesigned, implemented, integrated andtested as incremental builds. This model ismore applicable where softwarerequirements are well defined and basicsoftware functionality is required early.
  18. 18. 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.
  19. 19. DISADVANTAGES OF INCREMENTALMODEL- Each phase of an iteration is rigid (notchanged) and do not overlap each other.- Problems may arise pertaining to systemarchitecture because not all requirementsare gathered up front for the entire softwarelife cycle.
  20. 20. RAD MODEL
  21. 21. RAD MODEL DEPLOYMENT TEAM # N Integration, Delivery, Feedback MODELLING Business, data & process modeling CONSTRUCTIONCOMMUN 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
  22. 22. 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. Paretos 80 - 20 Rule usually results in reducing the costs to create a custom system.
  23. 23. 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.
  26. 26. Spiral Model
  27. 27. Since end-user requirements are hard toobtain/define, it is natural to develop softwarein an experimental way: e.g.4. Build some software5. See if it meets customer requirements6. If no goto 1 else stop.
  28. 28. This loop approach gives rise to structured iterative lifecycle models.In 1988 Bohem developed the spiral model asan iterative model which includes riskanalysis and risk management.Key idea: on each iteration identify and solvethe sub-problems with the highest risk.
  30. 30. Cumulative cost Evaluate alternatives,Determine objectives, Identify & resolve risksalternatives & constraints Prototypes OperationalReview & Start P1 P2 P3 Prototypecommitment 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
  31. 31. Each cycle follows a waterfall model by:2. Determining objectives3. Specifying constraints4. Generating alternatives5. Identifying risks6. Resolving risks7. Developing next-level product8. Planning next cycle
  32. 32. Advantagesn Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirementsn Flexible: incoporates the advantages of the waterfal and rapid prototyping methodsn Comprehensive model decreases riskn Good project visibility.
  33. 33. 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.
  34. 34. open source software
  35. 35. 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
  36. 36. 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.
  37. 37. Typical OSS development model Improvements (as source code) and Developer evaluation results: User as DeveloperDevelopment Trusted Bug ReportsCommunity 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)
  38. 38. 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 Apples Mac OS X.
  39. 39.  examples of open source software Internet  Apache, which runs over 50% of the worlds 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.
  40. 40. 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
  41. 41. open source software sites Free Software Foundation Open Source Initiative see also individual project sites; e.g.,;; etc.
  42. 42. 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
  43. 43. open source software development Users Documenters Users Bug reporters Patchers Maintainers Core developer(s) Users Users
  44. 44. 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)
  45. 45. open source licensing see  apache software license  python license  ibm public license  apple public source license etc.
  46. 46. Unified Process
  47. 47. 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 customers view of a system.
  48. 48. HISTORYDuring 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.
  50. 50. Inception Elaboration Transition ConstructionUP Lifecycle – single phase workflow (drawn as a UML Statechart!)
  51. 51. Unified Process ProductManagement Software LifecycleEnvironment * * releases Workflow CycleRequirements Inception 4Design Phase ElaborationImplementation Construction *Assessment Iteration TransitionDeployment * Artifact
  52. 52. Documentation
  53. 53. Documentation as part of the software life cycle ProgrammingSpecifications Documentation Testing Maintenance
  54. 54. What is Documentation Anything written or printed Relied on as a record of proof for authorized persons Vital part of professional practice
  55. 55. 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?
  56. 56. Some quality aspects of good documentation concise complete up-to-date free of jargon well organized accurate consistent
  57. 57. Parts of a good user manual Table of contents (two levels if necessary) Conventions What’s new Content Appendix Index
  58. 58. Configuration management
  59. 59. What is a Configuration?A configuration is the “functional and physicalcharacteristics of hardware or software” as setforth in technical documentation or achieved ina product.What is SCM?Software configuration management (SCM) isresponsible to establish and maintain the integrity ofthe products of the software project throughout thesoftware life cycle.This includes identifying configuration items,controlling changes and recording and reporting thechange implementation status.
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. System families PC Mainfram e version version VMS versionInitial D EC Workstationsystem version version U nix version Sun version
  64. 64. 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
  65. 65. 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
  66. 66. Symptoms of poor CMS Bugs that have been corrected reappearB Previous releases of software cannot be rebuiltP Previous releases of software cannot be foundP Files get lostF Files are “mysteriously” changedF The same or similar code exists multiple timesin different projectsi Two developers accidentally change the samefile concurrently
  67. 67. 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
  68. 68. 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
  69. 69. Risk Management
  70. 70. 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
  71. 71. 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
  72. 72. 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
  73. 73. 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
  74. 74. 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…)
  75. 75. 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…)
  76. 76. Risk IdentificationExample of Social Engineering
  77. 77. Risk Identification Breaches  Michelangelo virus  ‘I Love You’ virus  ‘Good Times’ hoax  Kevin Mitnick Failures  Head crash  Staff absence
  78. 78. Four Facets of Security1. Confidentiality  Access control, unobservability, Anonymity2. Integrity  Physical integrity, rollback, separation of duties3. Availability  Containment, robustness, recovery4. Accountability  Audit, id & authentication, trusted path…
  79. 79. 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
  80. 80. Questions?