A Presentation on“Software Engineering and Project Management” Course Code : IT-605 Presented by : MANOJ KUMAR SONI
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.
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.
TOOLS METHODS PROCESS A QUALITY FOCUSFIG. : SOFTWARE ENGG. LAYERS
– 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
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
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.
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
Waterfall Model / Linear Sequential model / Classic Life Cycle Model.
COMMUNICATION PLANNING MODELING CONSTRUCTION DEPLOYMENT FIG: WATERFALL MODEL
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.
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
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.
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
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.
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.
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.
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
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.
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.
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.
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.
Spiral Model PLANINGCOMMUNICATION MODELING START DEPLOYMENT CONSTRUCTION
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
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
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.
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.
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
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.
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)
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.
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.
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
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.
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
open source software development Users Documenters Users Bug reporters Patchers Maintainers Core developer(s) Users Users
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)
open source licensing see http://www.opensource.org/licenses/ apache software license python license ibm public license apple public source license etc.
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.
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.
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.
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
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
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
System families PC Mainfram e version version VMS versionInitial D EC Workstationsystem version version U nix version Sun version
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
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
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
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
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
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
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
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
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
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…)
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…)
Risk IdentificationExample of Social Engineering
Risk Identification Breaches Michelangelo virus ‘I Love You’ virus ‘Good Times’ hoax Kevin Mitnick Failures Head crash Staff absence
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…
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