Embed Size (px)
Citation preview
Software Development Process
• Activities and steps • Models • Supporting disciplines • Tools
Activities & Steps
• Requirements • Specification• Architecture • Design• Implementation • Testing• Deployment • Maintenance
Models
• Agile • Cleanroom • DSDM• Iterative • RAD • RUP • Spiral• Waterfall • XP • Scrum • V-Model
Supporting Disciplines
• Configuration management• Documentation• Quality assurance (SQA)• Project management• User experience design
Tools
• Compiler • Debugger • Profiler• GUI designer• Integrated development environment
Definition
• A structure imposed on the development of a software product
• A.k.a software life cycle & software process• International standard for describing the
method of selecting, implementing and monitoring the life cycle for software is ISO 12207 (23 Processes, 95 Activities, 325 Tasks and 224 Outcomes)
Requirement Analysis
• Domain Analysis is often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system
• Software Elements Analysis: extracting the requirements.
• Incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers . This is in concern with the Software Process Activity/Steps
Requirement Analysis (cont’d)• The process where clients requested to give details
as to what exactly the software should do for them; what exactly do they want the software to achieve; what expected output/results are expected
• The process tries to gather and understand various elements of software that needs to be engineered
• This process can be achieved through question and answer sessions. Demonstration of similar products can also help the clients to give unambiguous answers to the questions asked
Requirement Activities
• Eliciting requirementsCommunicating with customers and users to determine what their requirements are. Also called requirements gathering
• Analyzing requirementsDetermining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues
• Recording requirementsDocumenting requirements in various forms, such as natural-language documents, use cases, user stories, or process specifications
Types of Requirements • Customer Requirements
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS).
• Functional Requirements Explanation what has to be done, and identified The necessary task, action or activity that must be accomplished
• Performance Requirements The extent to which a mission or function must be executed; Generally measured in terms of quantity, quality, coverage, timeliness or readinessDuring requirements analysis, performance requirements will be interactively developed across all identified functions based on system life cycle factors; Characterized in terms of the degree of certainty in their estimate, degree of criticality to system success, and their relationship to other requirements
Types of Requirements (cont’d)• Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals
• Derived Requirements Implied or transformed from higher-level requirementExample: a requirement for long range/high speed may result in a design requirement for low weight
• Allocated Requirements Established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirementsExample: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items
Specifications
• The task of precisely describing the software to be written, possibly in a rigorous way
• In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development
• Most important for external interfaces that must remain stable
• A good way to determine are sufficiently precise is to have a third party review the documents making sure that the requirements and Use Cases are logically sound
Architecture
• An abstract representation of that system• Concerned with making sure the software
system will meet the requirements of the product, as well as ensuring that future requirements can be addressed
• Addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system
Design, Implementation & Testing
• Implementation is part of process where software engineers actually program the code for the project
• Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible
• Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal
Deployment & Maintenance
• Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment
• Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it
Deployment & Maintenance• People are often resistant to change and avoid venturing into an
unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software
• Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software
• It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do
Agile Software Development
• Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software
• Interestingly, surveys have shown the potential for significant efficiency gains over the waterfall method. For example, a survey, published in August 2006 by VersionOne and Agile Alliance and based on polling more than 700 companies claims the following benefits for an Agile approach
Rapid Application Development• A software development methodology, which
involves iterative development and the construction of prototypes
• It is a merger of various structured techniques, especially the data driven Information Engineering with prototyping techniques to accelerate software systems development
• RAD calls for the interactive use of structured techniques and prototyping to define user's requirements and design the final system
Rapid Application Development (cont’d)
• Pros– Promotes strong collaborative atmosphere and dynamic
gathering of requirements– Business owner actively participates in prototyping, writing test
cases and performing unit testing
• Cons– Dependency on strong cohesive teams and individual
commitment to the project. Success depends on disciplined developers and their exceptional technical skills and ability to “turn on a dime”. Decision making relies on the feature functionality team and a communedecision making process with lesser degree of centralized PM and engineering authority.
Iterative Process
• Iterative development prescribes the construction of initially small but even larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want
Extreme Programming
• The best-known iterative process • In XP, the phases are carried out in extremely small
(or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model.
• First, one writes automated tests, to provide concrete goals for development
Extreme Programming (cont’d)
• Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed
• Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding
• The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.
Chaos Model
• A structure of software development that extends the spiral model and waterfall model
• The phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code
• The whole project must be defined, implemented, and integrated
• Systems must be defined, implemented, and integrated• Modules must be defined, implemented, and integrated• Functions must be defined, implemented, and integrated• Lines of code are defined, implemented and integrated
User Experience Design • Often abbreviated UX or UE, is a term to describe the
overarching experience a person has as a result of their interactions with a particular product or service, it's delivery, and related artifacts, according to their design
• Typical outputs include:– Flows and Navigation Maps – User stories or Scenarios – Persona (Fictitious users to act out the scenarios) – Wireframes (screen blueprints or storyboards) – Prototypes (For interactive or in-the-mind simulation) – Written specifications (describing the behavior or design) – Graphic mockups (Precise visual of the expected end result)
User Experience Design (cont’d)
• Reducing excessive features which miss the needs of the user
• Improving the overall usability of the system • Expediting design and development through
detailed and properly conceived guidelines • Incorporating business and marketing goals
while catering to the user
Waterfall Processes
• Requirements specification (AKA Verification) • Design • Construction (AKA implementation or coding) • Integration • Testing and debugging (AKA validation) • Installation (AKA deployment) • Maintenance
Waterfall Processes (cont’d)• After each step is finished, the process proceeds to the next step,
just as builders don't revise the foundation of a house after the framing has been erected.
• This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management."
• Often the supposed stages are part of review between customer and supplier, the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills
Other Models • Capability Maturity Model (CMM) is one of
the leading models. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced
• ISO 9000 describes standards for formally organizing processes with documentation
Other Models (cont’d)
• ISO 15504 (Software Process Improvement Capability Determination)is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team
Other Models (cont’d)• Six Sigma is a methodology to manage process
variations that uses data and statistical analysis to measure and improve a company's operational performance. It works by identifying and eliminating defects in manufacturing and service-related processes. The maximum permissible defects is 3.4 per one million opportunities. However, Six Sigma is manufacturing-oriented and needs further research on its relevance to software development
Other Models (cont’d)• Test Driven Development (TDD) is a useful output of the Agile camp
but some suggest that it raises a conundrum. • TDD requires that a unit test be written for a class before the class is
written. The class firstly has to be "discovered" and secondly defined in sufficient detail to allow the write-test-once-and-code-until-class-passes model that TDD actually uses
• This counter to Agile approaches, where developers are still encouraged to code early, with light design
• To get the claimed benefits of TDD a full design down to class and responsibilities is not necessary. This would count towards iterative development, with a design locked down, but not iterative design - as heavy refactoring and re-engineering might negate the usefulness of TDD
Software Project Management
• Project planning, monitoring and controlThe purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion.
Software Project Management (cont’d)
• Project monitoring and control To keep the team and management up to date on the project's progressIf the project deviates from the plan, then the PM can take action to correct the problem. Involves status meetings to gather status from the teamWhen changes need to be made, change control is used to keep the products up to date
Software Configuration Management• Task of tracking and controlling changes in the software• Include revision control and the establishment of baselines• Goals– Configuration identification (What code are we working
with?) – Configuration control (Controlling the release of a product
and its changes)– Status accounting (Recording and reporting the status of
components)– Review (Ensuring completeness and consistency among
components)
Software Configuration Management (cont’d)
– Build management - Managing the process and tools used for builds
– Process management - Ensuring adherence to the organization's development process
– Environment management - Managing the software and hardware that host our system
– Teamwork - Facilitate team interactions related to the process
– Defect tracking - Making sure every defect has traceability back to the source
Software Documentation• Requirements: Identify attributes, capabilities, characteristics,
or qualities of a system• Architecture/Design: Overview of software. Includes relations
to an environment and construction principles in design of software components
• Technical: Documentation of code, algorithms, interfaces, and APIs
• End User: Manuals for the end-user, system administrators and support staff
• Marketing: How to market the product and analysis of the market demand
Software Quality Assurance
• Software quality control is a control of products, software quality assurance is a control of processes
• Through PPQA audits: Process and Product Quality Assurance is the activity of ensuring that the process and work product conform to the agreed upon process
• Advantages– Improved customer satisfaction– Reduced costs of development– Reduced costs of maintenance
Software Development Rythms• The approach of software development rhythms seeks to answer the key
question of whether programmer productivity is impacted by the various agile practices, rather than by any single software development method.
• Example:– plan ~ do ~ check ~ act ~ plan ~ do ~ check ~ act ... – pair programming ~ solo programming ~ pair programming ~ solo
programming ... – testing ~ coding ~ refactoring ~ testing ~ coding ~ refactoring ... – test first programming ~ test last programming ~ test first
programming ~ test last programming ... – standardizing ~ tailoring ~ measuring ~ improving ~ tailoring ~
measuring ~ improving ...
Problem in Software Projects• Come from 3 different viewpoints: PM, developers and
customers• The problems of PM: poor roles definition, lack of estimating
& planning skills, lack of decision making skillsDo need to face schedule, budget & quality constraints
• The problems of developers: lack of knowledge in the application area, lack of knowledge about developing standards, lack of up to date documentations, deadline pressure, changes of application requirements
• The problems customers face include: monetary constraints, receiving products past the due date
GUI Builder• A graphical user interface builder, or GUI designer is a
software development tool that simplifies the creation of GUIs by allowing the designer to arrange widgets using a drag-and-drop WYSIWYG editor
• A GUI must be built by manually specifying each widget's parameters in code, with no visual feedback until the program is run.
• User interfaces are commonly programmed using an event-driven architecture, so GUI builders also simplify creating event-driven code. This supporting code connects widgets with the outgoing and incoming events that trigger the functions providing the application logic.
Compiler
• A computer program that translates text written in a computer language into another computer language
• The original sequence is usually called the source code and the output called object code
• A program that translates from a low level language to a higher level one is a decompiler
• To perform many or all of the following operations: lexical analysis, preprocessing, parsing, semantic analysis, code generation, and code optimization
Debugger• A technique that allows great power in its ability to halt when
specific conditions are encountered but which will typically be much slower than executing the code directly on the appropriate processor.
• When the program crashes, the debugger shows the position in the original code if it is a source-level debugger or symbolic debugger,
• If it is a low-level debugger or a machine-language debugger it shows the line in the disassembly
Debugger (cont’d)
• Offer more sophisticated functions such as running a program step by step (single-stepping), stopping (breaking) (pausing the program to examine the current state) at some kind of event by means of breakpoint, and tracking the values of some variables
• The importance of a good debugger cannot be overstated. Indeed, the existence and quality of such a tool for a given language and platform can often be the deciding factor in its use, even if another language/platform is better-suited to the task
Performance Analysis• A.k.a profiling: investigation of a program's
behavior using information gathered as the program executes
• Goal: To determine which sections of a program to optimize - usually either to increase its speed or decrease its memory requirement
Performance Analysis (cont’d)• Instrumentation
– Manual: Done by the programmer, e.g. by adding instructions to explicitly calculate runtimes.
– Compiler assisted: Example: "gcc -pg ..." for gprof, "quantify g++ ..." for Quantify
– Binary translation: The tool adds instrumentation to a compiled binary. Example: ATOM
– Runtime instrumentation: The program run is fully supervised and controlled by the tool. Examples: PIN, Valgrind
– Runtime injection: Code is modified at runtime to have jumps to helper functions. Example: DynInst
Training Lead
• LinkedIn: www.linkedin.com/in/goutama• Email: [email protected]• Google+: www.gplus.to/goudotmobi• Skype: goudotinfo• Twitter: @goudotmobi
