software engineering processes lecture 3. advanced software engineering- asst prof athar mohsin,...
TRANSCRIPT
Software Engineering Processes
Lecture 3
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST2
Terms & Definitions • Process
– A process describes the sequence of steps that a knowledgeable professional should follow to do a specified task.
• Defined Processes– A documented sequence of steps required to do a specific job.
• Processes are usually defined for jobs that are done repeatedly and need to be done in the same way each time that they are performed.
• Process & Plans– Processes and Plans include both the process steps and other
elements required for a specific instantiation of that process:• such as resources needed, roles of various project members, schedules,
budget, goals and objectives, commitments, and identified risks.
• Process Phases – A defined process consists of a set of steps,
• Any process must have three phases: planning, development, and postmortem.
Software Process • A software process can be defined as the coherent set of policies,
organizational structures, technologies, procedures, and artifacts that are needed to conceive, develop, deploy, and maintain a software product.
– Software Process: A Roadmap by Alfonso Fuggetta
– Software development technology:• Technological support used in the process (Tools, Techniques, infrastructure, envo
etc).
– Software development methods and techniques:• organizations and people
– Organizational behavior:• Science of organizations and people
– Marketing and economy. • must address real customers’ needs in specific market settings.
• Software process models often represent a networked sequence of activities and events that represent strategies for accomplishing software evolution.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST3
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST4
Essential Phases of any Software Development Process
• Essential Phases:
– Requirements Elicitation, Analysis, Specification
– System Design
– Program Implementation
– Test
• Each Phase has an “Output”– Software Requirements
Specification (SRS), Use Cases– Design Document, Design
Classes, – Code– Test Report, Change Requests
• Process Model – Different projects may interpret these phases differently.– Each particular style is called a “Software Life-Cycle Model”– Serve as a basis for planning, organizing, staffing, coordinating,
budgeting, and directing software development activities• How software is or should be developed.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST5
SWEBOK Guide = 10 Knowledge AreasMapped TO ISO/IEC 12207:1995 processes
Software Quality
Software Engineering Tools and Methods
Software Engineering Process
Software Engineering Management
Software Configuration Management
MaintenanceTestingConstructionDesignRequirements
Primary Processes
Supporting Processes
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST6
Criticism
• Criticism on software development
• Counter criticism– widespread adaptation and use of software process
methodologies
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST7
Requirem entsEngineeringProces sRequirem entsE lic itationRequirem entsAnalysisRequirem entsSpecif icationRequirem entsValidationRequirem entsM anagem en t
S o ftw a reR e q u ire m e n ts
Software DesignBasic ConceptsKey Issues inSoftware DesignSoftware S tructureand ArchitectureSoftware DesignQ uality analysisand Ev aluationSoftware DesignNotationsSoftware DesignStrategies andM ethods
S o ftw a reD e s ign
Linguistic M ethodsForm al M ethodsV isual M ethods
Reduc ation inCom plexity
Linguistic M ethodsForm al M ethodsV isual M ethods
Anticipation o fD iversity
Linguistic M ethodsForm al M ethodsV isual M ethods
Structuring for validation
Linguistic M ethodsForm al M ethodsV isual M ethods
Use of Externa lS tandards
S o ftw a reC o n s tru c tion
Basic ConceptsandDefin itionsTest LevelsTest TechniquesTest-related M easuresM anaging the Tes tProces s
S o ftw a reT e s t
BasicConceptsM aintenanc eProces sKey issuesInSoftwareM aintenanc eTechn iquesforM aintenanc e
S o ftw a reM a in te na n ce
M anagem ent of theSCM ProcessSoftwareConfigurationIdentficationSoftwareConfigurationContro lSoftwareConfigurationS tatus AccountingSoftwareConfigurationAuditingSoftware Releas eM anagem en tandDelivery
S o ftw a reC o n fig u ra tionM a na ge m e nt
O rgaqnizationa lM anagem en tProcess/ProjectM anagem en tSoftwareEngineeringM easurem en t
S o ftw a reE n g in e ering
M a na ge m e nt
Engineering P roces sConceptsProcess InfrastructureProcess M easurem en tProcess DefinitionQ ualitative Proces sAnalysisProces sIm plem entationand C hange
S o ftw a reE n g in e ering
P ro ce ss
Requirem entsToolsDesign toolsConstruc tion toolsTesting toolsM aintenance toolsEngineering P roces sToolsQ uality toolsCongifurationM anagem en tToolsEngineeringM anagem en tToolsInfrastructureSuppor tToolsM iscellaneous too lIssues
SoftwareTools
Heuristic M ethodsForm al M ethodsPrototyping M ethodsM iscellaneous m ethodIssues
SoftwareM ethods
S o ftw a reE n g in e ering
T o o ls & M eth o ds
Q ualityConceptsDefin ition& P lanningfor Q ualityTechn iquesRequ iring2 or m orePeopleSupport toothe rTechn iquesTesting Specia lToSQ A or V&VDefect F indingTechn iquesM easurem ent inSoftware Q ualityAnalysis
S o ftw a re Q u a lity
S W E B O K
• A structured framework for development
Software Engineering Body of Knowledge
(IEEE/ACM Stone-man Version 0.9 February 2001)…
WWW.SWEBOK.ORG
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST8
Today’s Discussion
• The Software Engineering Process KA can be examined on two levels. – First level encompasses:
• The technical and managerial activities within the software life cycle processes that are performed during software acquisition, development, maintenance, and retirement.
– Second is the meta-level, which is concerned with the:
• Definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle processes themselves.
(IEEE/ACM Stone-man Version 0.9 February 2001)…
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST9
Software Engineering Process• The term “software engineering process” can be
interpreted in different ways, and this may cause confusion.– One meaning, where the word the is used (the software
engineering process), could imply that there is only one right way of performing software engineering tasks.
• Avoid this interpretation, because no such process exists.
– IEEE12207 standard Software engineering processes, meaning:
• There are many processes involved, such as Development Process or Configuration Management Process.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST10
Software Engineering Process- SWEBOK
• Another meaning refers to the general discussion of processes related to software engineering.
• Yet another meaning could signify the actual set of activities performed within an organization, which could be viewed as one process, especially from within the organization.
• Software engineering process related activities are relevant to and have been performed successfully:– Large organizations, Small Organizations, Teams, and
Individuals.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST11
Software Process Many different software processes but all involve:
Specification – defining what the system should do; Design and implementation – defining the organization of the system
and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing customer
needs.
A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.
Basic Steps of Software ProcessThe basic Software Process has three phases. 1. Planning: Produce a plan to do the work. 2. Development: Perform the work.
a. Define the requirements b. Design the program c. Review the design and fix all defects d. Code the program e. Review the code and fix all defects f. Build / compile and fix all defects g. Test the program and fix all defects
3. Postmortem: Compare actual performance against the plan, record process data, produce a summary report, and document all ideas for process improvement.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST12
Software Process Knowledge Area
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST13
Software Engineering Process • Focuses on organizational change. It
describes:– The infrastructure, activities, models, and
practical considerations for process implementation and change
• Process evolution
• Process Infrastructure– The resources must be available and the
responsibilities assigned• Competent staff, tools, funding and commitment
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST14
Software Process Management Cycle• The mgmt of SW processes consists of four
activities sequenced in an iterative cycle:– Establish Process Infrastructure activity– The Planning activity:
• To understand the current business objectives• To identify strengths and weaknesses• To make a plan for process implementation and
change.– The Process Implementation and Change activity:
• To execute the plan, deploy new processes (involve, the deployment of tools and training of staff)
– Process Evaluation:• Finding out how well the implementation and change went.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST15
Process Infrastructure activity• A team using a well structured Programming
language to develop a system, effect of change ( from C to OOP):– Technical issues
• Effect of change e.g from C to OOP, requires education, training, techniques and appropriate time to get conversant
– Management problem• understand the implications of using the new technology plus the
change in culture within the organization, • secondly managing the current system, plus the time lost through
all the training and education plus the change over to the new system.
– Resourcing issues including:• cost of training, loss of technical and managerial resource during
training, cost of additional consultancy etc,
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST16
Process Definition • Software Life Cycle Models
– serve as a high-level definition of the phases that occur during development.
– Aimed to highlight the key activities and their interdependencies
• Waterfall model, through away prototyping model, evolutionary development, incremental/iterative delivery, the spiral model, the reusable software model
• Software Life Cycle Processes– More detailed than software life cycle models
• Information Technology — Software Life Cycle Processes [IEEE 12207.0-96].
• Some software life cycle processes emphasize rapid delivery and strong user participation, namely agile methods such as Extreme Programming
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST17
Development Vs Process models – Software process models based on the evolutionary development of
applications are being recognized as important for success in the production of commercial software. (Argument #1)
– Important aspect of software development is conformance to an appropriate process model? (Argument #2)
• Take any process model as example and view it from verity of following – Good technical team– Use of the right tools– Use of the right method of computation– Clear and stable set of requirements– Good configuration management and change control– Good project management (technical and personnel)– Good planning
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST18
IEEE Support to Process Lifecycle • The IEEE 1074:1997 standard on developing life cycle
processes:– Provides a list of processes and activities for software development
and maintenance• A list of life cycle activities which can be mapped into processes and
organized in the same way as any of the software life cycle models
– Standard identifies and links other IEEE software standards to these activities
– Standard can be used to build processes conforming to any of the life cycle models
• Standards which focus on maintenance processes are IEEE Std 1219-1998 and ISO 14764: 1998
• IEEE/EIA12207, contain mechanisms and recommendations for accomplishing the adaptation.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST19
IEEE Std 1074: Standard for Software Lifecycle
IEEE Std 1074IEEE Std 1074
Project Management
Project Management
Pre-Development
Pre-Development
Develop-ment
Develop-ment
Post-Development
Post-Development
Cross-Development
(Integral Processes)
Cross-Development
(Integral Processes)
> Project Initiation>Project Monitoring &Control> Software Quality Management
> Concept Exploration> System Allocation
> Requirements Analysis> Design> Implemen- tation
> Installation> Operation & Support> Maintenance> Retirement
> V & V> Configuration Management> Documen- tation> Training
Process Group
Processes
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST20
IEEE/ISO 12207 • ISO 12207 offers a framework for software life-cycle
processes from concept through retirement. – Suitable for acquisitions:
• Recognizes the roles of acquirer and supplier– It is not applicable to the purchase of commercial-off-the-shelf (COTS)
software products.
– Provides a structure of processes using mutually accepted terminology
• “shall" to indicate mandatory provisions, • "should" for recommendations, and • "may" for permissible actions
• The standard is based on two basic principles: – modularity and responsibility.
• Modularity means processes with minimum coupling and maximum cohesion.
• Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST21
A Sample 12207 Development Process
Process Implementation Activity
Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution
Organizational Processes: Management, Infrastructure, Improvement, Training
One example of applying 12207 to the Waterfall development strategy
SystemQual Test
System Integra-
tion
Software Installation
Software Acceptance Support
Software Item 1:
Sys ArchDesign
System Reqts
Analysis
SoftwareQual TestSoftware
Integra- tionSoftware
Code & TestSoftware
Detailed Design
Software Arch.
DesignSoftware Reqts.
Analysis
Software Item 2:
SoftwareQual TestSoftware
Integra- tionSoftware
Code & TestSoftware
Detailed Design
Software Arch.
DesignSoftware Reqts.
Analysis
Hardware items
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST22
Tailoring 12207• 12207 should be tailored for a project - no two projects are
the same• Tailoring considerations:
– Life cycle activity: prototyping, maintenance– Software characteristics: COTS, reuse, embedded firmware – Org’s policies, languages, hardware reserve, culture– Acquisition strategy: contract type, contractor involvement– Life cycle strategy: waterfall, evolutionary, spiral, etc.
• The Tailoring Process (12207.0 )1. Identify project environment - strategy, activity, requirements2. Solicit inputs - from users, support team, potential bidders3. Select processes, activities, documentation, responsibilities4. Document tailoring decisions and rationale
What CAN’T be tailored: the intent or objectives
What CAN be tailored: number of phases/activities, roles, responsibilities, document formats, formality/frequency of reports or reviews
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST23
Example Process activities
• Software specification– The process of establishing what services are required
and the constraints on the system’s operation and development.
• Software design and implementation– The process of converting the system specification into an
executable system. Major Process activities are:• Architectural design, Abstract specification, Interface design• Component design, Data structure design, Algorithm design
– Software design• Design a software structure that realises the specification;
– Implementation• Translate this structure into an executable program;
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST25
The software design process• Deriving a solution which satisfies software requirements
– Architectural design: Identify sub-systems.
– Abstract specification: Specify sub-systems.
– Interface design: Describe sub-system interfaces.
– Component design: Decompose sub-systems into components.
– Data structure design: Design data structures to hold problem data.
– Algorithm design: Design algorithms for problem functions.
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST26
Process Activities • Different processes organise activities in different ways &
are described at different levels of details.– Real time software in aircraft
• has to be completely specified before the development
– eCommerce system • the development and the specification could be together
• Use of inappropriate process, – probably reduce the quality or the usefulness of the software
product
• Generic process models– Waterfall– Evolutionary development– Integration from reusable components
• CBSE– Upper-CASE Tools to support the early process activities of requirements and
design– Lower-CASE Tools to support later activities such as programming, debugging and
testing
• There are many variants of these models
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST27
Plan-driven and agile processes
Plan-driven processes:Processes where all of the process activities are planned
in advance and progress is measured against this plan.
Agile processes:Planning is incremental and it is easier to change the
process to reflect changing customer requirements.
In practice, most practical processes include elements of both plan-driven and agile approaches.
There are no right or wrong software processes.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST28
Why focus on process? •Process provides a constructive, high-leverage focus...–as opposed to a focus on people
• Your work force is as good as it is trained to be.• Working harder is not the answer.• Working smarter, through process, is the answer.
–as opposed to a focus on technology• Technology applied without a suitable roadmap will not
result in significant payoff.• Technology provides the most benefit in the context of an
appropriate process roadmap.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST29
Software lifecycle Process Models • Lifecycle - The steps through which the product
progresses• Software life cycle models serve as a high-level definition of
the phases that occur during development. – They are not aimed at providing detailed definitions but at
highlighting the key activities and their interdependencies. – Examples of software life cycle models are
• Build-and-fix model
• Waterfall model
• Rapid prototyping model
• Incremental model
• Extreme programming
• Synchronize-and-stabilize model
• Spiral model ………… Process Models
Process Improvement
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST30
Build and Fix Model• Problems
– No specifications– No design
• Totally unsatisfactory for any reasonable size software
• Need life-cycle model– Phases– Milestones
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST31
Waterfall Model• The only widely-used model
until the early 80’s• Characterized by
– Feedback loops– Documentation-driven – Each phase needs to be
approved by SQA
• Advantages – Enforced disciplined approach– Documentation– Maintenance easier
• Disadvantages– Specifications not easily
understood by clients
• Deficiencies – All requirements must be known upfront– Deliverables created for each phase are considered
frozen – inhibits flexibility– Can give a false impression of progress– Does not reflect problem-solving nature of software
development – iterations of phases– Integration is one big bang at the end– Little opportunity for customer to preview the system
(until it may be too late)
• When to use – 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.
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST32
Rapid Prototyping Model• Rapid prototype – a working
model functionally equivalent to a subset of the product– Determine what the client needs– When developed, the client and
users try using it– When they are satisfied, the
process moves to the next phase
• Linear model– Specifications are drawn from the
rapid prototype– Feedback loops are not used
• “Rapid” is the key
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST33
Integrating Waterfall and Rapid Prototyping Models
• Waterfall model– Many successes– Client needs may not be met
• Rapid prototyping model– Some success but not really proven – Has own problems
• Solution– Rapid prototyping for requirements phase– Waterfall for rest of life cycle
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST34
SDLC• V-Shaped SDLC Model
– A variant of the Waterfall that emphasizes the verification and validation of the product.
– Testing of the product is planned in parallel with a corresponding phase of development
• Project and Requirements Planning – allocate resources
• Product Requirements and Specification Analysis – complete specification of the software system
• Architecture or High-Level Design – defines how software functions fulfill the design
• Detailed Design – develop algorithms for each architectural component
• Production, operation and maintenance – provide for enhancement and corrections
• System and acceptance testing – check the entire software system in its environment
• Integration and Testing – check that modules interconnect correctly
• Unit testing – check that each module acts as expected
• Coding – transform algorithms into software
• Strengths – Emphasize planning for verification and validation of
the product in early stages of product development– Each deliverable must be testable– Project management can track progress by
milestones– Easy to use
• Deficiencies – Does not easily handle concurrent events– Does not handle iterations or phases– Does not easily handle dynamic changes in
requirements– Does not contain risk analysis activities
• When to use– Excellent choice for systems requiring high
reliability – hospital patient control applications
– All requirements are known up-front– When it can be modified to handle changing
requirements beyond analysis phase – Solution and technology are known
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST35
Incremental Model• The product is designed,
implemented, integrated and tested as a series of builds
• A build consists of code pieces from various modules interacting to provide a specific functionality
• Too few builds can lead to build-and-fix model
• Too many builds can lead to inefficient development
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST36
Concurrent Incremental Model
• More risky version—pieces may not fit– CABTAB (code a bit and test a bit) and its dangers
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST37
Spiral Model• Simplified Waterfall model
plus risk analysis– Uses rapid prototypes
• Precede each phase by– Alternatives– Risk analysis
• Follow each phase by– Evaluation– Planning of next phase
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST38
Spiral SDLC Model• Adds risk analysis, and RAD
prototyping to the waterfall model
• Each cycle involves the same sequence of steps as the waterfall process model
– Objectives: functionality, performance, hardware/software interface, critical success factors, etc.
– Alternatives: build, reuse, buy, sub-contract, etc.– Constraints: cost, schedule, interface, etc.
Spiral QuadrantDetermine objectives, alternatives and constraints
Spiral QuadrantEvaluate alternatives, identify and resolve risks
• Study alternatives relative to objectives and constraints
• Identify risks (lack of experience, new technology, tight schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by continuing system development
Spiral QuadrantDevelop next-level product
• Typical activities:– Create a design, Review design– Develop code, Inspect code– Test product
Spiral QuadrantPlan next phase• Typical activities
– Develop project plan
– Develop configuration management plan
– Develop a test plan
– Develop an installation plan
• Strength – Provides early indication of risks, without much cost– Users see the system early because of rapid
prototyping tools– Critical high-risk functions are developed first– The design does not have to be perfect – Users can be closely tied to all lifecycle steps– Early and frequent feedback from users– Cumulative costs assessed frequently
• Deficiencies – Time spent for evaluating risks too large for small or low-risk
projects– Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive– The model is complex – Risk assessment expertise is required– Spiral may continue indefinitely– Developers must be reassigned during non-development phase
activities– May be hard to define objective, verifiable milestones that indicate
readiness to proceed through the next iteration
• When to use – When creation of a prototype is appropriate– When costs and risk evaluation is important– For medium to high-risk projects– Long-term project commitment unwise because of
potential changes to economic priorities– Users are unsure of their needs– Requirements are complex– New product line – Significant changes are expected (research and
exploration)
• Suitability to modern SDLC– Appreciation of risk, – The possibility of stopping a project that
exhibited too much risk, – knowledge of the phases (determine objectives,
identify and assess risk, develop and verify next-level product, and plan next phase)
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST39
Agile SDLC’s• Speed up or bypass one or more life cycle phases
– Usually less formal and reduced scope– Used for time-critical applications– Used in organizations that employ disciplined methods
• Some Agile methods – Adaptive Software Development (ASD) – Feature Driven Development (FDD) – Crystal Clear – Dynamic Software Development Method (DSDM) – Rapid Application Development (RAD)– Scrum – Extreme Programming (XP) – Rational Unify Process (RUP)
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST40
Extreme Programming
• Approach based on the incremental model– Development team determines stories (features client
wants)– Estimate duration and cost of each story– Select stories for next build– Each build is divided into tasks– Test cases for task are drawn up first– Pair programming– Continuous integration of tasks
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST41
Differences of Agile• Focus on collaboration:
– Less paperwork and more conversation– Stakeholders actively involved
• Focus on working software:– Greater feedback makes agile projects easier to manage– Less documentation is required– Less bureaucracy
• Agilists are generalizing specialists:– Less hand offs between people– Less people required– Specialists find it difficult at first to fit into the team
• Agile is based on practice, not theory:– This is a significant change from traditional
– You need to see how agile works in practice to truly understand it
Agile Common Practices •Regular Deployment of Working Software•Pair Programming•Refactoring•Continuous Integration•Test Driven Development (TDD)•Shared Code Ownership•Active Stakeholder Participation
Agile Common Practices •Regular Deployment of Working Software•Pair Programming•Refactoring•Continuous Integration•Test Driven Development (TDD)•Shared Code Ownership•Active Stakeholder Participation
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST42
Agile Myths Vs Reality
Myth1. No Documentation
2. Undisciplined
3. No Planning
4. Not Predictable
5. Does Not Scale
6. Is a fashion
7. Silver Bullet
8. RUP isn’t agile
9. Not Fixed Price
Reality
1. Agile Documentation
2. Requires great discipline
3. Just-in-time (JIT) planning
4. Far more predictable
5. Eclipse is agile
6. It’s quickly becoming the norm
7. It requires skilled people
8. RUP is agile
9. Agile provides stakeholders control over the budget, schedule, and scope
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST43
Agile vs. Plan Driven Processes
1. Small products and teams; scalability limited
2. Untested on safety-critical products
3. Good for dynamic, but expensive for stable environments.
4. Require experienced Agile personnel throughout
5. Personnel succeed on freedom and chaos
1. Large products and teams; hard to scale down
2. Handles highly critical products; hard to scale down
3. Good for stable, but expensive for dynamic environments
4. Require experienced personnel only at start if stable environment
5. Personnel succeed on structure and order
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST44
Organization& Meetings
Roles &Responsibilities
Processes
Measures
Policies &Standards
Mission & Principles
Agility - Set of Practices
Practical Governance Body
Staged Program Delivery
Simple And Relevant Metrics
Continuous Project Monitoring
Iterative Development
Adapt The Process
Risk-Based Milestones
Continuous Improvement
Embedded Compliance
Manage Project Pipeline By Business Value
Scenario-Driven Development
Self-Organizing Teams
Align HR Policies With IT Values
Align Organization Structure With Architecture
Integrated Lifecycle Environment
Valued Corporate Assets
Flexible Architectures
Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST45
References• Guide to the Software Engineering Body of Knowledge: 2004
• Trip, Leonard L., Professionalization of Software Engineering: Next Steps,
• “A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession”,
• “An Assessment of Software Engineering Body of Knowledge Efforts: A Report to the ACM Council“,
• Humphrey, W.S. (1990). Managing the Software Process. Addison-Wesley Publishing Company, New York, NY.
• Process Models in Software Engineering, Walt Scacchi, Institute for Software Research, University of California, Irvine
• M. B. Chrissis, M. Konrad and S. Shrum, CMMI: Guidelines for Process Integration and Product Improvement, Pearson Education Inc., Boston, 2003.
• Scott W. Ambler, www-306.ibm.com/software/rational/bios/ambler.html