Software Development Process

[jimin-kiim]

• Software Development Process
• Software Development Process Model

[jimin-kiim]

Software Development Process

• a development of project is composed of a number of activities
• development of project > activities > tasks: resources -> work product
  • an activity is composed of a number of tasks.
  • a task consumes resources and produces a work product.
    • resources: participants, time or an equipment
    • work product: system, model or a document

Activities

• Requirements Elicitation : creating use case model
• Analysis : expressing sw project in terms of application domain objects
• System Design (Architecture Design): structuring sw project into subsystems
• Detailed Design (Object Design): realizing solution domain objects of project
• Implementation: implementing sw project by source codes
• Testing: verifiying project by test cases

Software Development Process

• set of activities and their relationship to develop sofware
• it bring order to the chaos of software development
• aka, SDLC(Software Development Life Cycle)
• can be represented with software development process model
• there are two types of process; Plan-driven and agile processes

Plan-driven and Agile processes

• Plan-driven processes
  • process activities are planned in advance
  • progress is measured against this plan
• Agile Processes
  • planning is incremental
  • it's 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's no right or wrong software processes

[jimin-kiim]

Software Development Process Model

• an abstract representation of a software process
• Sequential models
  • waterfall model
  • V-model
• Iterative models
  • Spiral model
  • UP & RUP

[jimin-kiim]

Waterfall Model

• a classic life cycle model
• linear sequence of phases
  • a phase starts only when the previous one is reviewed and verified
  • the phases partition the project, each addressing a separate concern
• plan-driven approach
• advantages
  • conceptually simple; cleanly divides the problem into distinct phases
  • natural approach for problem solving
  • easy to administer in a contractual setup; each phase is a milestone
• disadvantages
  • assumes that requirements can be specifies and frozen early
  • 25% change in requirements is typical in software projects, and it is impossible to freeze the requirements early on.
  • may fix hw and other technologies too early
  • follows the big bang approach; all or nothing delivery -> too risky
  • requirements bloating
  • it is a proven fact that on average 45% of the features of waterfall projects was never used.
  • very document oriented; requiring docs at the end of each phase
• usages
  • has been used widely
  • well suited for projects where the requirements can be understood easily and the technology decisions are easy.
  • mostly used for large systems engineering projects where a system is developed at several sites for a long duration
  • e.g., military, aerospace industries

    V-model

• transformation of waterfall model
• makes explicit dependency between development activities and verification and validation activities
• as requirements are specified and components are designed, the testing for those elements is defined, too.
• advantages
  • ensure high quality and relevant testing
  • maximize test effectiveness
• disadvantages
  • suffers from the rigidity of the waterfall model

[jimin-kiim]

the arrival of iterative and incremental development

Background

• requirements always change
  • business changes lead to new and changed system requirements
  • new technologies open up new possibilities for improving implementations
  • changing platforms require application changes
• changes lead to rework so the costs of change include both new functionality and rework

  Development of Prototype

• Prototype
  • in prototype, only key features which need better understanding are included.
  • no point in including those features that are well understood
  • feedback from users taken to improve the understanding of the requirements
  • the quality of prototype is not important and exception handling, recovery, standards are omitted
  • advantages
  • requirement will be more stable
  • requirement can be frozen later
  • experience helps in the main development
  • disadvantages
  • potential hit on cost and schedule
  • usages
  • useful when the requirements are hard to elicit
  • when the confidence in requirements is low

    Iterative and Incremental Development

• delivers a series of releases that provides progressively more functionality for the customer as each increment is delivered
• newer approaches like UP, Agile,... all rely on iterative development
• organized in a series of fixed-length iterations
  • each iteration includes its own requirement analysis, design, implementation, integration and testing
• advantages
  • risk reduction
  • build-feedback-adapt cycle-> helps resolve and prove the risky and critical design decisions early rathe than late.
  • less project failure
  • flexibility to modifications
  • efficient feedback
  • higher quality
  • a chance to improve the process itself
  • the learning within an iteration can be used to improve the development process itself, iteration by iteration
  • early visible progress
  • early feedback, user engagement and adaptation
  • lead to a refined system that more closely meets the real needs of the stakeholders
  • managed complexity
  • the team would not be. overwhelmed by 'analysis paralysis' or very long and complex steps
• disadvantages
  • architecture/ design may not be optimal
  • rework may increase, total cost may be more
• usage
  • when the response time is important
  • when the risk of long projects cannot be taken
  • when all the requirements are not known

how long should an iteration be?

• iterations should be short; between 2- 6 weeks
  • less than 2 weeks: too short for meaningful throughput and feedback
  • more than 6 weeks: complexity becomes overwhelming
• iterations should have fixed length. timeboxing
  • if it seems difficult meeting the deadline, de-scope it and move tasks or requirements to future iterations

[jimin-kiim]

Spiral model

• a number of cycles are iteratively progressed
• a cycle includes several sectors
  • object setting
  • specific objectives for the phases are identified
  • risk assessment and reduction
  • risks are assessed and activities put in place to reduce the key risks
  • development and validation
  • a development model for the system is chosen which can be any of the generic models
  • planing
  • the project is reviewed and the next phase of the spiral is planned

[jimin-kiim]

UP & RUP

• a software development approach that is iterative, architecture-centric, use-case driven
• UP is an open software development process from the authors of UML
• RUP is a Rational process product, which is a commercial subclass that both extends and overrides UP features

  UP

• a popular iterative sw development process for building object-oriented systems
• iterative, architecture-centric, use-case driven
• risk-driven
  • identify and drive down the high risks
  • risk driven iterative development includes more specifically the practice of architecure-centric iterative development; early iterations focus on building, testing and stabilizing the core architecture. it's because not having a solid architecture is a common high risk.
• client-driven
  • build visible features that clients care most about
  • writing use cases with customers
  • requirements workshops that include both developers and customers
  • a demo of the results of each iteration to the customer -> feedback

    4 phases of UP

    Inception Phase(-> Lifecycle Objective Milestone)

• the purpose of inception: to collect just enough information for vision, business case, scope, vague cost estimates, feasibility of a project
  • no iteration and should be short
    • a short requirements workshop; one week for most projects
  • most requirement analysis occurs during the elaboration phase, not inception.
  • artifact
  • most actors, goals and use cases are named
  • most use cases are written in brief format ( only 10-20% are written in fully dressed detail)
  • most influential and risky requirements are identified
    • risk list is writtern
  • version1 of the Vision and Supplementary Specification is written
  • much UML diagramming is not required.
  • technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements
  • user interface oriented prototypes to clarify the vision of FR
  • recommendations on what components to buy, build, reuse to be refined in elboration
  • high-level candidate architecture and components are proposed
  • plan for the first iteration
  • candidate tools list
  • inception has more focus on understanding the basic scope
  • in practice, most UML diagramming will occur in the next phase, elaboration.

    Elaboration Phase(-> Lifecycle Architecture Milestone)

• initial series of iterations of
  • building the core architecture (create a stable baseline architecture)
  • resolving the high risk elements ( mitigate risks)
  • defining more requirements
  • estimating the overall schedule and resources
• start programming early
• adaptively design, implement, test the core and risky parts of the architecture
• test early, often, realistically
• adapt based on feedback from tests, users, developers
• write most of the use cases and other requirements in detail
  • through a series of workshops, once per elaboration iteration
• progresses through a few iterations
• artifacts
  • domain model: visualization of domain concepts ~= static information model of the domain entities
  • conceptual class diagram
  • OOA
  • design model: set of diagrams that describes the logical design
  • software class diagram, object interaction diagram, package diagram
  • OOD
  • software architecture document
  • summarizes the key architectural issues, and their resolutions in the design
  • data model: database schemes, mapping strategies between object and non-object representations
  • use-case, UI prototypes: description of the UI, paths of navigation, usability models and so on

    Construction Phase(-> Initial Operational Capability Milestone)

• develop the remainder of system as efficiently as possible
• iterative implementation of the remaining lower risk and easier elements, and preparation for deployment
• progresses through several iterations

  Transition Phase(-> Product Release)

  • beta tests, deployment
  • get customer acceptance of the product
• progresses through a few iterations
• artifact: a general term for any work product
  • e.g.,code, web graphics, database schema, text documents, diagrams, models, etc.
• discipline: a set of work activities and related artifacts in one subject area
  • e.g., writing a use case -> use case, implementing a module -> source files of the module
• UP disciplines: Business Modeling, Requirements, Design, implementation, Test, Deployment, Configuration & Change Management, Project Management, Environment
• several requirements artifacts (all optional)
  • use-case model
  • primarily for functional requirements
  • supplementary specification
  • primarily for non-functional requirements
  • captures and identifies other kinds of requirements
    • URPS+ (usability, reliability, performance, supportability, +)
    • constraints, standards, licensing, ...
  • common functionality, URPS
  • reports, hw sw constraints, development constraints, other design and implementation constraints, internationalization concerns, documentation, licensing and other legal concerns, packaging, standards(technical, safety, quality), physical environment concerns
  • glossary
    • captures terms and definitions
    • a data diactionary
  • vision
  • summarize high-level requirements
  • summarize the vision of the project
  • an executive sumary
  • business rules
  • requirements or polices
  • capture long-living spanning rules or policies that transcend one particular application

    RUP

• an iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release

[jimin-kiim]

use case ranking

• organize requirements and iterations by
  • risk: technical complexity, other factors such as uncertainty of effort or usability
  • coverage: all major parts of the system are at least touched on in early iterations
  • criticality: refers to functions the client considers of high business value