Software Engineering, Week 2 Notes
Software Engineering, Week 2 Notes CSC4110
Popular in Software Engineering
verified elite notetaker
Popular in Computer science
This 3 page Class Notes was uploaded by Judy on Friday September 9, 2016. The Class Notes belongs to CSC4110 at Wayne State University taught by Vaclav Rajlich in Fall 2016. Since its upload, it has received 7 views. For similar materials see Software Engineering in Computer science at Wayne State University.
Reviews for Software Engineering, Week 2 Notes
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 09/09/16
OneNote Online https://onenote.oﬀiceapps.live.com/o/onenotefram... Week 2 Notes Tuesday, September 06, 201610:23 PM History of Software Software is everywhere People who develop software possess the tools and skills to allow them to develop and evolve software Diﬃculties Programmers Face Accidental Current, past and future technology Quirks of the OS, compilers, languages, processes These tend to come and go Essential Subset of the deﬁning properties There are no easy answers to these Essential Diﬃculties Invisibility Senses are not easily used in comprehension Visualization and soniﬁcation requires a lot of work Complexity Programs are among the most complex systems out there Our short term memory only accommodates approx. 7 things at a time Changeability Software is constantly changing Yesterday's comprehension may be obsolete today Conformity Programs glue the large system all together, and reﬂects said large system This adds to the complexity Discontinuity People are able to easily understand linear and semi-linear systems (continuous) Discontinuity is when a small change of input can result in a large change in the output Software Engineering A set of recommendations of how to develop software A discipline with lots of knowledge The beginning of Software Engineering Software separated from Hardware in the 1950s Original programmers were recruited from current hardware engineers and mathematicians who used their ad-hoc methods from their former ﬁelds Paradigm A coherent tradition of scientiﬁc research (deﬁnition) Consists of not only the ideas, but also the investment Currently an overused terms Anomaly An important fact that directly contradicts the old paradigm Dilemma: To disregard the anomaly or to shift paradigms To shift is to abandon the large investment in the old paradigm The anomaly must be compelling enough to make a shift seem like the better option Paradigm Shift Discontinuity in the development of a discipline (a revolution) Paradigm shift of 1970 Established the discipline of software development Dealt with the complexity and made design an important consideration Introduced the waterfall metaphor Waterfall Metaphor Good design avoids expensive work later Became the dominant paradigm in the past A major contributor to software cost Waterfall Paradigm Has elaborate up front activities (Big Design Up Front) 1 of 3 09/09/2016 07:58 PM OneNote Online https://onenote.oﬀiceapps.live.com/o/onenotefram... Textbooks are still largely based on waterfall Anomaly of Requirements Volatility 30% or more of initial requirements can change during development Standish Group Anomaly Waterfall did not solve the problems of software development Many projects were cancelled, only 16% were considered successful Band-Aid's Prototyping - problem is that volatility continues after the prototype is developed All three of the paradigms currently coexist 1.Ad-hoc where software development is more of an art than engineering 2.Waterfall, which works if there is no volatility 3.Evolutionary paradigm which is currently mainstream 9/8/2016 CHAPTER 2 – Lifespan Models The stages that software goes through from life to death Software is a product, and it follows a similar lifespan though some stages may be diﬀerent Product Lifespan Introduction -> Growth -> Maturity -> Decline Software Lifespan Unique proprietary software follows the same curve, though the stage names are diﬀerent Staged Model 1.Initial Development: The ﬁrst version of the software is introduced 2.Evolution: Evolution changes the software up until it stops 3.Servicing/Maintenance: Patches are released for the software until it stops 4.Phase Out: The software goes into decline until it is switched oﬀ, maintenance stops 5.Close Down: Software is obsolete Initial Development Includes requirements, design, and implementation Fundamental decisions are made in regards to technology, architecture, and program domain knowledge Evolution Adapting the software to user operations and environment Adding new features, correcting mistakes, responding to learning and changes in technology The software usually grows during this time Software architecture and team knowledge make evolution possible Evolution Stops Can be cause by a managerial decision, software stabilization or code decay Code Decay Loss of software coherence, software knowledge, key personnel Challenge of software development is to slow down or eliminate code decay Servicing/Maintenance No additions to functionality are made Changes are limited to patches and wrappers The process is very diﬀerent from evolution There is no need for senior engineers The process is very predictable Reversal from servicing This is expensive and rare It is not simply a technical problem, but software team knowledge must be recovered Reengineering Uses the same model but servicing goes back to the evolution stage Phase Out No more servicing is being undertaken Users must work around the deﬁciencies 2 of 3 09/09/2016 07:58 PM OneNote Online https://onenote.oﬀiceapps.live.com/o/onenotefram... Close Down Software use is disconnected Users are directed toward a replacement An exit strategy is needed Versioned Staged Model Used by software with many users Versions of the software are released in stages rather than all at once Incomplete Lifespan Often happens with discontinued projects, stable domains (waterfall) Development can sometimes start with evolution Lifecycle vs Lifespan There is no cycle, so lifecycle is technically incorrect Lifespan is better terminology V model Modiﬁed waterfall, looks like a V Left branch follows same as waterfall Right branch is the testing and maintenance Prototyping Model Requirements -> Prototype -> Corrected requirements -> Design -> Implementation -> maintenance Attempts to prevent volatility 3 of 3 09/09/2016 07:58 PM
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'